Architecture for the sake of architecture is tiresome, which is what you are at least saying a little bit in this article.

However, lets not pretend that good (I will avoid the word clean since that seems triggering) architecture has no place in software. We need to be sure we are applying the patterns and principles that make sense for what we are building and maybe make compromises in other areas where we must... But in order to do this effectively we need to know Clean (Damn, I said it. Sorry.) Architecture Patterns.

In general, I don't like comparing Software architecture to the construction of a house like so many do, like you have quoted in your article. When we do so, we lose sight of the fact that unlike a house, if software is built correctly, foundational frameworks can be changed/swapped out without having to demolish the entire building. Try changing the foundation of a house and see how that goes for you.

Using an example you used, Abstractions and layers in software can ensure your product has longevity and allows you to refactor in stages rather than having to demolish everything. I will concede that some folks take this too far and try to abstract away things that likely will never change or where the abstraction won't benefit them anyway.

So for those who find this article when trying to learn Clean Architecture, read it and truly understand what the Author is saying. Then continue learning about Clean Architecture. You know need know it thoroughly to make educated decisions on what to patterns to use and where.