Another reason for one-class-per-file that hasn't been mentioned in the answers posted so far is that one-class-per-file makes it easier to understand the impact of a PR during a code review. It also reduces merge conflicts.
When someone posts a PR for feedback I can look at the list of files changed and immediately see any overlap with what I might be working on. Depending on the overlap I might want to look at their code more deeply or give it an OK because I'm fairly confident it isn't going to affect my own changes.
When two people are working in a multi-class file and both add a dependency there's a good chance you'll get a merge conflict in the using block at the top. Separating the classes into files separates the dependencies so you can see what each class is using and you don't get conflicts like this.
There are exceptions to this rule (interface + implementation, enums, ...) but it's a better starting place than the opposite which typically lets junior developers bundle all manner of unrelated classes into the same file.
One-class-per-file is a clear unambiguous rule not subject to interpretation.
Related-classes-in-a-file is subject to personal preferences and interpretation (as you can see from all the other answers here as
to when it's OK to use) and thus is a poor rule.
