Hexagonal architecture (ports and adapters): worth the complexity?

We're considering adopting hexagonal architecture (ports and adapters) for a new mid-size service our 5-person team is building. The idea of isolating business logic from external concerns (databases, APIs, UI) is really appealing for testability and maintainability. However, it also introduces a fair bit of boilerplate code with interfaces, adapters, and DTOs. My main concern is whether the added complexity and indirection are worth it for a relatively small team and a mid-size service. Will we actually see the benefits of easy swapping of infrastructure, or will it just slow us down with unnecessary layers? I've seen projects where the team spends more time managing the 'architecture' than delivering features. Does anyone have experience applying hexagonal architecture in a team of our size? What are some practical tips for keeping it lightweight and pragmatic? Any project structure examples that avoid excessive boilerplate while still reaping the benefits?