However..in my experiences thus far, this type of cohesion becomes increasingly complex and open to individual interpretation when you are dealing with more complex business domains. Say for example, several different types of customers engaging in several different types of transactions that have just enough differences in implementation to be several distinct models. Often there are several reasonable ways to interpret "functionality", and you end up with a situation where you are actively building what can be a fairly tricky form of technical debt over the course of years as developers come and go. From what I have experienced, the best way to avoid this, is of course more formality on the development team about structuring what goes where, but then you just end up with a different but still just as rigidly enforced structure as the first example from this article. It also has the downside of being non-standardized.
If I were going into some creature's "house", when they may very well be an alien creature whose domain and existence I understand little of, I personally feel most safe in the house that had the more "absurd" structure. I may have to walk down a few more hallways, but I won't blast myself with a ray gun looking for a faucet.