1. Paradigm: The paradigm of Object Oriented Programming follows directly from its definition of an object: a structure that contains both data and behaviour. Objects are your first class citizens. "Everything is an object" is, for most, a goal. Everything else, all the variations on how to formulate it or how the language implements it, are interpretations of how to do that.
2. Object-Oriented Programming Languages: I agree, everybody has their axe to grind with another language. This is no different from other programmers. On the flip side, for most this axe-grinding is pretty light-hearted. In a world as big as the OOP one, rivalries are everywhere.
3. Classes: "There is a complete disconnect in OOP between the source code and the runtime entities". Because the runtime entities contain data. Classes determine the behaviour on that data. It's a direct consequence of nr. 1. OO Code shows us the behaviour of an object, interacting with the behaviour of other objects. Everybody is free to dislike it, but calling it 'nonsensical' is ridiculous. As an aside: there are IDEs that show objects. BlueJ (https://en.wikipedia.org/wiki/BlueJ) comes to mind. They tend to be educational tools, because seeing and inspecting actual objects during development means you still need to work on how you mentally model the code.
4. Methods: Methods should be a sensible length. Make them as short and as sweet as is possible, but no shorter. If you need to go bouncing around huge amounts of tiny methods to figure out what is going on, you have a code smell. If you have to search through a 1000-line monster of a method to figure out what is going on, you have a code smell too. The goal is to find a sweet spot, not to apply some rules to their extreme.
5. Types: I'll be short on this one: the point of types is to make sure you don't accidentally do something stupid. In the process, they make other things harder, but also more predictable. If you don't like that, no problem, there are OO languages that are dynamically typed, or ducktyped, or any other variation on the theme.
6. Change: I don't quite know what the author means with change here. He seems to mix up change of the program (maintenance, extension, etc.), with change in the program's environment.
7. Design Patterns: A standard way to solve a standard problem. Refusing to use them or not knowing them will lead to either bugs or reinventing them. If they 'make your design more complicated', you're using them wrong.
8. Methodologies: Are a general problem in all programming, and always have been.
9. UML: I'm a professional developer. I almost exclusively do OOP. I haven't touched UML in years. I haven't seen UML in years, not from other developers, not from architects, not generated by the code. The code is the code, the modelling language is a way to communicate about the structure of the code. Reversing that relationship just means you're hiding code behind a graphical representation. See also: BlueJ.
10. The Next New Thing: Happens everywhere.
The conclusion sounds like a complete inversion of the original premise of the article. I agree we have a long way to go in OOP, and I agree we are still in the early days of OOP. But hating OOP is as shortsighted as hating FP, or procedural programming, or any other paradigm.