My experience has been that “clarity and organization” - especially in larger projects, is not enhanced by dramatically increasing the number of files involved. In fact, I have found the exact opposite to be true.
We don’t even begin to think about splitting apart our models.py files until they’re at least 2000 lines, and will let them get to about 2500 before taking action. (And, in some cases - typically when external databases are involved, that “action” ends up being “do nothing” because we recognize there’s no benefit in those cases by splitting up the models.)
And, in those cases where we do choose to do something, as often as not it ends up being a situation where we split a whole chunk of functionality off as a separate app.
I can respect the fact that you have that opinion. We (the development team I am a part of) don’t share that opinion and disagree with the conclusion. We all have backgrounds with large Java-based projects and have concluded that the “one-class-per-file” default standard is extremely counter-productive and have found much practical benefit in the “fewer-files-are-better” approach.