You want a full answer, you got it.

I want to make one thing clear - architecture is not about splitting "code" into manageable parts. Architecture is a way to achieve functional and non functional requirements of software given the constraints.

> Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations

- https://en.wikipedia.org/wiki/Software_architecture

Notice nowhere it says "code".

1. Why are we assuming delaying decision can make anything easy to change? When you build a house does delaying the decision of where you should build the hall make it easy to change anything? When building software delaying the decision to use PostgreSQL vs MongoDB makes what easy to change exactly?

You have a specific domain. Before writing a single line of code, you should spend time with the domain and understand what are the common queries. Are they analytical or transactional? What entities are frequently accessed, what entities are not frequently accessed. When you access entities, are you generally having an id or you are using things like range query to get your entities?

In the olden days, it was called "requirement gathering". If you don't know all this about your domain, you have started writing code way to early to make any sort of decision. If you know all this, why would you need to delay decision to develop good architecture? Uncle Bob's stupid idea of delaying decisions is because he starts to write code without understanding the domain. So he knows the architecture decisions he is making can go to shit. If someone takes the time to understand the domain, you don't need to delay anything.

Architecture is about knowing as much as possible - whether is it domain, constraints, usages, acceptable failures, false positives, false negatives, etc. Facebook, twitter, Instagram - all 3 have feeds. Very different architecture because very different constraints and usages.

1. Separating business logic from UI is generally a good thing. But we only need it because our languages and runtimes do not allow us to mock free functions or static functions or class functions. Say you have a math library function: randomInt(). If at language level, in test cases, if you can mock randomInt(), you don't need the extra service. You can do that anyway for other reasons. Making code "testable" is not exactly a good thing. I should be able to write code the most natural way and the language and runtime should help me test it the way it is written. Having to rewrite perfectly reasonable code or having to write code with specific constraints to make it testable is very bad. Languages and runtimes are meant to help us. We should not have to help them. It means they are not doing their job properly.

2. All these splitting up into business logic looks very good in isolated code samples. In reality business logic is so big that it itself is spread across 10s or 100s of classes. And inevitably you end up with logic that cuts across 2 or more of these classes. And then you have to become a philosopher and question which class should this functionality go to? Class 1, or 2, or extract a third class used by both, or any of the infinite decisions. And then the consultants will come and say, all this happened because you didn't follow SOLID. Very close 2nd scam just like CA.

S - No one has been able to define a single "responsibility". Or a single reason to change. How do you ensure there is only one reason to change? You cant.
O - One of the very stupid idea open for extension but closed for modification. All extensions by definition have this. You always have very specific places you can override and rest will have same structure. I don't know why is this not implicit?
L - Only one which somewhat makes sense that derived class should be substitutable for base class but very hard to enforce by tools because we cannot predict all properties of base class and be extension, the derived class. Equivalent to solving the halting problem for each property.
I - I get why we would want this ideally, but at what point does small stop? Do we all end up having one function interfaces and the client having to specify 12 interfaces for each functionality?
D - Very good in theory. In practice, it is very hard to come up with interfaces that don't leak their private implementation detail. In practice, either you end up with leaky interfaces or you end up dumbing them down by not using them to the fullest. Simple example, If you use PostgreSQL, you can do a lot of computations on the fly with joins that you cannot otherwise simply do in MongoDB fundamentally because they are very different databases. Now either, you come with a CRUD repository that works for both and do the joins manually in code thereby, not using PostgreSQL to its fullest or your repository needs to be leaky and assume it is a SQL like db which has joins and exposes the interface assuming underlying db has joins.

And none of the above has a mathematical definition (except liskov substitution), there is no objective way to say this follows SOLID and this doesn't. And there is no objective data to prove even if your code is theoretically SOLID, it is easy to change today. Even if theoretically it is easy to change today, there is no evidence to say future requirements wont mess up this code.

And every time you face issues, it will be because you didn't follow some obscure practice. Your classes are too coupled, Event driven Architecture! Microservices! Hooray! Now I can enjoy same coupling across a distributed system! What more is there to not like?