From my experience, when I'm working on real world problems of nontrivial sizes and I see a big chunk of well organized, like a really well organized service, almost always it's because that was the latest cleanup/refactoring effort that happened after many years when the problem space was a moving target, and finally it stopped changing long enough to come up with a clean abstraction.
The cleanest code I've ever written has always been on the second or third try. Write it once, test it against the real world, then rewrite it to take the new discoveries into account. It's too bad we rarely have the luxury of breathing room to rewrite things.
I think it might be cause no one really knows what you're building until it's been built. Only until then (or even a little later) does the structure of the thing become apparent. Until you've got something most people agree is what everyone wanted, requirements are basically mush and so the code is too.
The cleanest code I've ever written (and got complimented on by others) was when I was the main dev on a rewrite of a legacy system. It's easy to focus on clean/well-tested code when you don't have to worry about business decisions and customers' main concern is that nothing changes, even existing bugs!
The cleanest code I've ever written has always been on the second or third try. Write it once, test it against the real world, then rewrite it to take the new discoveries into account. It's too bad we rarely have the luxury of breathing room to rewrite things.