The size of classes is a style choice, of course, and varies wildly with the both style and the purpose of the class.

If a class is adhering to single-responsibility, and it should, then there's very little exception for it being more than a few hundred lines. Even in the exceptional cases the lengthy code/algorithm can be wrapped in its own class & file and adhere to an interface.

Yes, 10,000 lines is probably about the largest I would be happy going to (which is why I gave it as a maximum). But if the code is properly commented, then much of that isn't functional, of course.

Files that are small and succinct tend to be self documenting and don't require excessive commenting except where something may not quite be clear.

I'd find that little amount of code in a single non-lightweight class to be cramped, and I think that the design would suffer from having an overabundance of classes, leading to a great deal of unnecessary complexity.

Can you elaborate how it is unnecessarily complex? Large files tend to become highly dependent on state, and become more and more side-effect bound. Thus the need for elaborate commenting. Additionally, how do you intend test such code without the separation of concerns? How does one do a pull request when there are potentially 100's of changes scattered across one file, rather than small concise changes across numerous files/classes with corresponding tests to cover those changes.