First, thanks for taking the trouble to read the book and write up a response (even if we end up disagreeing :)
I, at least, am an old Smalltalker, but Java isn't Smalltalk.
The thing about objects being things-that-you-send-requests-to is part of the Smalltalk tradition (Erlang enforces it even more strongly). This is a different school from the usual objects-as-classifications tradition.
The other part of the Smalltalk tradition is lots of small objects. This means it takes a while to get into a code base, but even longer to get into the style if you're not used to it. It's a significantly different approach if you're used to procedural and you should not take that transition for granted. The idea is that a system is made up of composable parts, so its behaviour is as much in the combination of objects as the code within them.
You should also remember that this is a small example intended to fit into 6 chapters in a book. Of course, it's a complicated way to achieve something that could probably be a page of python.
It sounds like you come from a significantly different tradition, where the most important things are not the same. I have worked on systems where we had very good data analysts who spent months coming up with the "perfect" data model. It broke within weeks of the start of coding and flushing out more detail. That's my confirming example of why I'm wary about that level of upfront work in my world -- although the prep really helped them understand the domain.
I'm a bit confused that you don't like message-sending, and then you propose an event bus.
Finally, I can't help thinking you'd get better responses from people if you don't tell them that their experience (and that of some of the most significant people in the field) is "stupid dogma". Not everyone else is an idiot. If you really want to read an object book, then Rebecca Wirfs-Brock's classic Object Design is now available somewhere as a PDF download for free.
S