At the end of the day, it's about solving problems with the budget you have. You need the appropriate discipline to allow for maintainability and growth, but not to over-engineer.

Boring CRUD is faster and more sustainable than an abstraction that cannot be modified for new requirements. Or understood by future (perhaps misfortunate) maintainers.

One day your thing will become the tech debt for your organization. Write in a way the custodians of the future won't curse your name.

I've inherited systems where the original authors tried to be "smart": over-use of functional programming, "cute" abstractions, "powerful" mixins, layers of lazily-dispatched decorators. It's almost ways caused nothing but headache and pain.

I agree. And the budget also limits the time you have for thinking about a really good design rather often unfortunately. Choosing the right or sometimes no abstraction is key to making something that is extensible, readable and maintainable.

That said, starting out with the simpler concept, usually results in better composability of parts. This is especially true for pure functions vs classes which are not really classes but namespaces artificially made into classes because "OOP". In the end math wins, if you wanna call it like that.

Having started in functional programming before ending up in OO, I always noticed the web was more functional than object oriented and a great deal of work was expended extrapolating languages to the web though frameworks to often achieve such an effect.