I think many "clean" abstractions are about making a certain layer (horizontals) in a tech stack is clean, whereas functional parts in actual applications are most cleanly separated as functional verticals. But if you follow a clean vertical separation you will run into issues when horizontals (like common styling in a web-app or coherent network failures handling in many applications ) isn't handled cleanly.
For really clean applications you want your design to be a DAG, focusing on horizontals or verticals often leaves people with messes when you violate DAG constraints in the other direction.
What the author has issues with is that React frontend-monoliths would need extra machinery to work with separate compilation steps to allow separate building of verticals, with something like HTMX it's fairly loose (And separately worked on verticals can easily co-exist).
I think that this is part of the big divide between people who came from classic web-dev backgrounds and more latecomers from other domains (often manifested by the love or hate of DHH and his anti-TS/React stance).
Web-dev people would naturally land on writing verticals (one page = one task) and whilst their common abstractions could be horrible (SQL everywhere) they accomplished tasks well but cleaning up architectural messes could be bad.
Classic developers outside of web often saw applications, servers,etc (horizontals) as their main unit and made those clean, keeping the horizontal clean (like network failure handling) would influence design decisions (often at the expense of vertical concerns).
React allows for composability internally but often re-introduces issues on a larger scale, like your Redux store needs to know about parts from perhaps both user-admin and more application specific tasks. Now this is fine if it's a separately distributed application (like a mobile app) but people used to just handle one vertical at a time might feel that it's a lot of extra work other more contained cases.