I think your point #2 "Not everyone understands OOP at the same level" explains pretty much all your remaining points. Developers that aren't very good at development, well, have a hard time building software that's maintainable. This is true regardless of how it's programmed. What you don't seem to realize is that most of the rest of the article demonstrates that you're on the wrong side of the line here.
I don't agree with commenters who feel it's their years of experience that put them on the right side of the line. When I was a graphic designer who stepped up to do the programming when a programmer on the project basically ghosted 25+ years ago, my instinct was to try to find other ways to do what I was doing than just follow the terrible model laid out for me. I later learned my instincts led toward OOP. OTOH, I have worked with many, many developers with 20+ years of experience who have no clue what Law of Demeter even is, let alone how to avoid violating it or why you would want to (for example). They don't even have an intuitive sense of it without the name. Sadly, I see more and more internet "experts" "discovering" practices that look a lot like what we were inverting when IoC became a thing.
The real question is how do you go from someone who has a gap in this area to someone who is on their way to not having a gap (everyone always can learn and do better, so I don't think there's anyone who couldn't use work)?
I think it boils down to TDD. Whether you're using functional programming or OOP, you will clarify for yourself and others what you're trying to do if you write the tests first AND you will have small, testable units (whatever they are). The tests serve both as documentation and code examples.
BTW, it is entirely possible to pull in functional elements into OOP, such as using reduce to send a group of promises in a loop and come up with one answer at the end. A good stepping stone between OOP and functional programming is to spend a lot of time understanding lodash and why each of its methods exists.