I would imagine that's why they had "best practices" in quotes. Lots of enterprisey things get pushed as a "good practice" to improve reuse (of things that will never be reused) or extensibility (of things that will never be extended) or modularity (of things that will never be separated).
Enterprise development has particular problems you won't find in other environments, for instance having hundreds of different developers with widely varying levels of skill and talent, all collaborating together, often under immense time and budget pressure.
The result ain't going to be what you get if you've got a focused group of 10x geniuses working on everything, but I think a lot of the aspects of "enterprise development" that people complain about is simply the result of making the best of a bad situation.
I like Java, because I've worked with people who will fuck up repeatedly without static type checking.
I can attest to that and see it as the reason why Angular is still so popular in the enterprise world - it has such a strong convention that no matter the rate of staff rotation the team can keep delivering.
Meanwhile no two React projects are the same because they typically have several dependencies, each solving a small part of the problem at hand.
> for instance having hundreds of different developers with widely varying levels of skill and talent
That's a management problem. Meaning you assess that risk and try to alleviate it. A good solution like you say is languages with good type checking support. Another is code familiarity and reuse through frameworks and libraries. A third may be enforcing writing tests to speed up code review (and checklist rules like that).
It's going to be boring, but boring is good at that scale.
