Layers are a lot easier to comprehend than hexagons. That makes other tasks easier, like planning deployment of layers into tiers, through which routes are similarly linear.
Think of P&A as terminology to help you disambiguate these use cases from the extremely overloaded words. If your team know these terms, it makes a lot of discussions a lot clearer.
The hexagon thing is a bit of a red herring IMO. I think of it as dependency inversion at the module level, rather than the class level.
On the other hand, "port" is already completely overloaded: serial interface, TCP socket endpoint, etc. Further overloading it - particularly when there is a widely used term for the same thing - makes no sense.
Reinventing terms for existing concepts does nothing - in my mind - to advance the state of art.
class FooService : IFooService{} interface IFooService {}
where there is an interface with a single implementation. In this case, the "service interface" isn't a port, because it's not actually decoupled from the domain.
It has the potential to be one, but only if the FooService is extracted, dereferenced from the domain, and the application composes the FooService.
Saying "we need to make this into a port and adapter" gets the point across very quickly.