A couple of comments:
I would encourage folks to look at the ~40 classes in Filters/Points that are point cloud filters (and there are more point cloud filters in other subdirectories too). They work just fine with any vtkPointSet as input. Generally the assumption in these is to ignore any topological information (verts, or cells of any type). However, you could easily use topological information (like verts, lines, etc) to carry additional information about the point cloud (which points are on/off, local neighborhood information, topological feature like edges, etc.) This could be very advantageous for hybrid point cloud algorithms.
Note that as new dataset types are added, these is a lot of work writing conversion filters to go between types. Also, there tends to be the need to add complexity to some filters to recognize new types. IMO having many types is vaguely reminiscent of having lots of template parameters - there is a lot of code spent dispatching and switching between types, and coding can feel like being in a straitjacket 
Finally a side note about point locators. The classes in Filters/Points use the vtkStaticPointLocator which, based on benchmarks I did a while back, are much faster than anything else in VTK - nothing comes close. However, the weakness of this locator (which I rarely see) is when there is huge spatial variation in spacing between points (e.g., transition to boundary layer). Because the performance of vtkStaticPointLocator is weakly connected to the binning resolution, generally the response is to crank up the resolution to very high values - which works to a point. If somebody wants to improve the point locator, I would focus on creating a hierarchical, static point locator. It would be cool to have, but would take some work.