If vtkPointCloud is not a subclass of vtkPolyData then we cannot use vtkPolyData to properly represent point clouds anymore. This is a major issue, because we still want to support point clouds in our applications and we would need to consider using vtkPointCloud class in addition (or instead of) vtkPolyData everywhere where we currently simply use vtkPolyData. Such mode would also hurt point cloud processing people because suddenly none of VTK filters would work on their data sets (they would need to temporarily convert to polydata and convert back; or they would need to update all filters to support both vtkPolyData and vtkPointCloud). The cost would be huge for very little benefit.
The only reason I can think of why a vtkPointCloud class could make sense is for marketing purposes: to show to lidar processing people that VTK supports point clouds (I can see that some people feel uneasy about using a class that has “poly” in its name for storing just points). For this, you could derive vtkPointCloud from vtkPolyData. This would not immediately break anything. However, there is high risk that having a separate child class, incompatibilities would start to creep in. For example, some new filters that are originally developed for point clouds, might only accept vtkPointCloud class and not vtkPolyData, not because it would not work with polydata, just because developers simply did not think or care about vtkPolyData compatibility when implementing it.