Let's suppose you want labels, text boxes, and buttons on a form.
Now you can do this without OOP or making a huge chunk of form code, but OOP is a natural fit. Especially if we may want to add pictures or video in the future.
Are you saying all these outlets (labels, text box, buttons) are inheriting from a base FormObject that can be rendered?
That would work without OOP. Make a FormRender component that manages that logic (being rendered in a form) and other components, one that manages a keyboard, other that can be clicked and handle hover, touch states, etc.
Sure, but routing get's complex in your solution. The point was OOP is a natural fit for collections of different types in some context ex:GUI, Simulation, etc. The classic OOP case is probably a MUD where OO code ends up being very straightforward.
IMO, the problem is it works really well in so many contexts that people end up trying to use it everywhere.
OO in MUDs seemed so natural to me, I think, because they're closer to the actor model that OO was really designed for. Instead of "methods", many objects in MUDs (depending on the system, I used to know more when I was research writing a MUD engine in erlang), respond to messages in more of a smalltalk-style.
ECS works well when you can predefine everything ahead of time. But, it must be extended for every additional type.
As to messaging, consider what happens when you add JavaScript that can change the DOM. Now, you need to pass messages in both directions not just What is your Height- Width, but also my Height-Width has changed. Animated Gifs or Videos now want to update things in real time, and other windows can cover parts of your view port.
And let's not forget about transparency.
PS: ECS can still work, but it starts getting really complex.
That would work without OOP. Make a FormRender component that manages that logic (being rendered in a form) and other components, one that manages a keyboard, other that can be clicked and handle hover, touch states, etc.