Clean code is all about code that aims to be understood by humans not machines. The same holds true for designing domains and organizing responsibilities. We want to find structures that easily tell the engineers what the project is all about.

The challenge with structuring by technical concerns at already high layers of abstractions is that the purpose and domain of the software gets obfuscated and hidden in lower layers of abstraction. When someone unfamiliar with the project looks at the code structure the first thing that they see are the three technical layers, although names and numbers might differ in some cases. This will at least look familiar to them, but it tells nothing about the actual domain.

Software engineers seek to understand domain modules, not necessarily technical layers.

For example, when touching the accounts functionality, developers regard everything related to the accounts domain, not all the database access classes at once. Other than that, developers hardly search for all database access classes, but for that single class which handles that logic of their current domain.

The same is true when changes have to be made to the system. Changes in functionality are more likely to affect all technical layers of a single or a few business domains, but hardly all classes of a single technical layer at once. For example, changing a field to the user account likely affects the user model, database accesses, business use cases, and even the presentation logic, but not necessarily all the other model classes as well.

To make the idea what aspects developers are interested in more clearer, let me give another example. Imagine a family organized their clothes in a single big wardrobe. They could cluster all pants from all family members in a single drawer, as well as separate drawers for all socks and all shirts, respectively. But the family members won't likely search for all pants at once when they try to dress. Rather than this, they're just interested in their individual clothes, be it pants, shirts, socks, or something else. Therefore, it would make sense for them to organize by several areas of the wardrobe first, one per family member and then structuring by technical clothes aspects second, ideally following a similar structure. The same can be seen for software responsibilities.