What I dislike about the term "clean" code is that it dismiss objective criteria.

"I did it like that because it's cleaner" is a non sense. A program must be maintenable, efficient, observable, testable, scalable, performant, readable, secured. Each criteria can be objectively measured in a kind of radar diagram and can be maximized as long as it does not sacrifice another criteria. Form follows function.

Even "simple" (from KISS) is too vague, fortunately in the conference "simple made easy" Rich Hickey defines what is simple: not interleaved. simple comes from sin plex, the opposite of con plex. Not always easy to make something simple.

However I don't see anything wrong with SOLID. Separation of concerns is how a modern society or a football team works, and S brings D because specialization involves good relationships ("no man is an island" wrote John Donne ), and D is strongly related to L. I has no drawbacks.

However I don't separate data from business logic anymore (no data access layer). Business logic applies on data, not on objects that hide data. Translating a ER diagram into anemic classes while the DBA do the same in the DB does not have any value and forces to use obstruction pattern like repository. If entity classes have properties and methods (a Plane class that has a 'takeOff' and 'land' methods for instance) it is different but must most backend I see don't implement entity classes that way. Because their classes represent data, not animated concept. Player class with a shoot method might makes sense for a video game, User class with a addComment method for a CRUD app makes less sense to me.

> A program must be maintenable, efficient, observable, testable, scalable, performant, readable, secured.

This is the key that most people miss.

The second thing most people miss is most of the time efficient, scalable, and performant are good enough. Not always, there are no absolutes, but most of the time you can safely compromise those 3 without any problem that the real world will notice. In general maintainable has proven to be the hardest/most expensive, and so clean code is most important (don't confuse with Clean Code as a book or any set of rules puts it). Indeed, observable and testable are just different ways to express maintainable. (the first is you can understand what went wrong, and the second you can ensure your changes don't break something else).

Secure is the final thing I didn't mention. this is becoming more and more important. It may even become more important than maintainable in the future.

> "I did it like that because it's cleaner" is a non sense. A program must be maintenable, efficient, observable, testable, scalable, performant, readable, secured. Each criteria can be objectively measured in a kind of radar diagram and can be maximized as long as it does not sacrifice another criteria. Form follows function.

I don't think it's nonsense. "Cleaner" here is just a different word that falls under your categories of readable and maintainable. More toward readable. Different word, same meaning.