How does Hexagonal architecture solve N-tier’s service spagetti?

I’ve seen a couple of talks on Hexagonal architecture where they illustrate problems with N-tier architecture. Specifically, they show a spaghetti of service layer dependencies as the software grows. For example, the image below is from the Hexagonal Architecture with Grails talk: https://www.infoq.com/presentations/hexagonal-arch-grails/

hexagonal architecture with grails

I agree this is typically where N-tier apps wind up as they grow. But I don’t really understand how hexagonal arch avoids or improves this situation. The business logic will still have the same dependencies. Those dependencies exist because some business code (whether intermingled with framework/persistence code or not), needs to call some other business code. Whether it’s in a service layer or in something we call “core” seems irrelevant.

Somewhat related is the concept of number of layers. While the talks on hexagonal architecture say it’s a single layer architecture (or outside versus inside), it all comes down to perception or how it’s drawn in diagrams. In my view it’s still N-tier, except we can call the web tier and data layer “adapters”. Whether it’s represented as horizontal layers or vertical slices seems more a matter of illustration or code organization. But the latter is often dictated by our framework.