I don’t think there is an inherent hate for components.
It’s more a case of splitting your code when there is a valid reason for it, rather than starting out automatically trying to come up with a component based architecture.
I’ve learnt from my own mistakes how starting out with an OOP style approach can cause you to run into difficulties - Rupert is trying to prevent people from making those same mistakes, but maybe sometimes it’s better to learn from them than avoid them without understanding why 
.
‘Components’ are not a bad thing in my view though. For instance, I’ve got a dropdown/select component that I use quite a lot in a current project. The reason I chose to build it as it’s own component is because I want specific behaviour from it, such as keyboard navigation, and as I need this in many places, it makes sense to me for this module to manage it’s own state, so that I don’t have all that replication of code across all the consuming modules (and repeated for every ‘instance’ in every module), and I didn’t want to push that responsibility on to every parent module. I also have the guarantee of the same behaviour everywhere without having to remember to handle all the keyboard events in every parent - so less chance of bug creeping in somewhere.
So I think there is a place for ‘components’, but not for ‘components’ sake.
Edit:
That’s not what anyone is suggesting, it’s simply easier to start out with a single file and single update function and then break it up when and where it makes sense.