There's plenty of maintainers who aren't that sort of a stick in the mud (even on the Linux kernel), the problem is that the Linux kernel has a few too many entrenched ones who are basically using their position to be a bully to interested contributors. They're generally aware enough that they know that the people they get into fights with aren't likely to use any of the official processes and are more willing to put up with it.
It's more akin to "this maintainer should be replaced" rather than "the entire management is bad"; to my understanding the actually important trees (as in, the server related components, since Linux is primarily used as a server kernel) don't have these maintainers; they're mostly on the stuff that matters less like well... Sleep/Wake related things, speakers and batteries, all of which are mostly useful for desktops and laptops.
For full clarity, having observed Marcans socials for a while, a big reason as to why upstreaming into the kernel is slow is because the Linux kernel suffers heavily from having BDFL maintainers.
Basically a specific maintainer can make upstreaming patches to their part of the kernel a process few people want to go through due to how much leeway they have in approving/rejecting patches. Stuff like yelling at merges that also happen to fix bugs in the parts that they modify because "bugs should be upstreamed separately" (even when splitting out the bugfix makes zero structural sense) or getting angry at contributors for lines they didn't contribute but that git diff happened to spit out around their commit to keep the diff readable.
Having watched that for a few weeks really gives you an understanding as to why so few Linux modifications for obscure devices have their patches upstreamed. (Switchroots main project, which is the Linux kernel but modified to run on the Switch for example doesn't bother upstreaming anything as far as I can tell.)