I agree with the part of your post where you show that checked exceptions are bad, but IMO Java has been OO from the start. And, if by procedural code you mean code that has zero abstractions, then, yes checked exceptions aren't a problem there because their big problem is you can't abstract over them. However, I find this statement more to be an obvious tautology than a statement that checked exceptions are really useful in any situation.
My bias there is that I'm one of those Alan Kay worshipping hard-liners who thinks there's a lot more to object-oriented programming than simply using objects. Similar to how there's more to functional programming than using first-class procedures.
So yeah, it's true, Java has classes. But its culture and idioms and standard libraries and even some language features (checked exceptions, for example) are forever pushing developers toward procedural idioms. Less so now, perhaps, but intensely so in the 1990s.
IIRC, Alan Kay says OO is message passing, encapsulation, and extreme late binding. In java:
* message passing is virtual method invocation
* encapsulation is through public vs private members
* late binding is through the JVM dynamic linking system.
While Alan Kay may have had something much more flexible like Smalltalk in mind, I believe the Java OO system meets the spirit of OO well enough and makes certain tradeoffs for good reasons.
Alan Kay was also fairly specific about what he meant by encapsulation, and it's not just making things private. For example, he wrote, "Doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming." And, later in the same paper, "Human programmers aren't Turing machines—and the less their programming systems require Turing machine techniques the better."
Java's programming culture tends to favor a shallower approach to OOP that cleaves very closely to the fiddly, imperative, state manipulation-oriented approach that is emblematic of procedural programming.
A great example of this is Java 8's streams API. There's absolutely no way to evaluate a stream without introducing a state change that will alter its behavior. Which means that, unlike for almost any other comparable API in another language, you can't safely pass around and share instances of Stream for fear that someone might break it on you. It's the shallowest possible interpretation of the abstraction in question, and making it that way was a deliberate decision that motivated by the tacit understanding that Java programmers have a fundamentally procedural way of thinking about the world, and would be confused by something that was truly declarative. The only other language I'm familiar with that takes the same approach is another popular "procedural programming with objects" language, Python.
This isn't to say that people can't do principled object-oriented programming in Java. Just that few people do. In part because, if you try, you'll end up constantly picking fights with the JDK. Not entirely unlike how you can do principled functional programming in Java, but it's an uphill struggle.
That statement is neat but it looks to have little to do with programming and more to do with programming style. What about Smalltalk, the language, for instance, helps you "eliminate state oriented metaphors" any better than any other programming language?
