The same rationale that applies to https://github.com/airbnb/javascript/tree/master/react#basic-rules (but also appears not to be documented): the whole point of modules is to make them as small and atomic and reusable as possible, which means splitting things up as much as possible.

Is there a specific use case where you think this rule shouldn't apply?

Thanks!
I'll have a look at our offending modules with the team to see if there's a case for keeping them together.

I would advocate for the use of a single module for model and controller classes for the same 'component' (in non-React ES6)

@SteveThorpe that presumes the MVC pattern is an ideal one to be following for the frontend, react or otherwise :-)

@ljharb MVC is far from ideal (IMO), even for our codebase. But if you are starting out with a codebase that is 'sort-of' MVC and, have a directive to impose AirBnb style on it, then the max-classes-per-file rule makes things worse (again, IMO)

@ljharb So would you agree that if you are stuck with the MVC pattern then you could be justified in turning off the max-classes-per-file rule? ;)

You can always turn off any rules that aren't a good fit for your use case - the Airbnb config assumes you're using Babel, targeting both web and node, using React, etc.