Are sponges inherently inefficient when compared to other
constructions?
In a way, yes. The sponge/duplex is serial rather than parallelisable. However, there are ways of making permutation-based cryptography parallel, like Farfalle, NORX, and AEGIS-128X/256X.
Furthermore, as mentioned by @Maarten Bodewes, there is increasingly SHA-3 hardware support, which boosts SHAKE based AEAD scheme performance, for example. Similarly, the hardware accelerated AES round function has been used for very efficient schemes in a way similar to the duplex construction. As an example, AEGIS-128X/256X is significantly faster than AES-OCB, AES-GCM, and ChaCha20-Poly1305 assuming the right hardware support. So are the non-parallelisable versions (AEGIS-128L and AEGIS-256), highlighting how duplex-style algorithms can be fast.
You also can't ignore the positives of the sponge/duplex constructions, such as ease of implementation, use case flexibility despite one primitive, considerable research, and so on. It has been the basis of many CAESAR and NIST LWC competition submissions, indicating a shift to permutation-based cryptography. If its performance was a problem, it would not have been this successful.
In return for that waste you get a MAC at the end - some claim that
it's for free for some reason.
The reason this is 'for free' is because a sponge-based AEAD scheme is one-pass rather than two-pass like generic composition. In other words, you don't have to process the message again.
AEADs like AES-GCM and ChaCha20-Poly1305 are sometimes called 1.5-pass because even though they do Encrypt-then-MAC, the MAC computation is faster than collision-resistant MACs like HMAC.
But the ops wasted on the hidden state cannot compete with something
like Poly1305.
This is a good thing. Poly1305 isn't collision resistant like the sponge/duplex, which is required for AEAD commitment. What people need to understand is that users of AEAD schemes intuitively expect them to have this property. Without it, vulnerabilities arise in protocols. If the aim is security by default/preventing misuse, all future AEAD schemes should be fully committing. The duplex is the most obvious and tried/tested way of doing this besides reverting to generic composition.
You can think of commitment as analogous to misuse resistance, except you would not intuitively expect a nonce-based AEAD scheme to be misuse-resistant. There are warnings about reusing a nonce everywhere. By contrast, nobody warns you about a lack of commitment and relatively few people understand when a protocol is vulnerable. Sure, there are 'patches' to existing AEAD schemes, but they're clunky (e.g. they increase ciphertext expansion or require replacing the AEAD tag, may produce timing side-channels during decryption, etc) or modify the scheme itself.
Or can you have an AEAD sponge construction that would allow a secure
full state involvement?
Again, full-state absorption prevents AEAD commitment, what should be a fundamental security property. If you're still unconvinced that this is a problem, ask yourself why NIST wanted to discuss it in the third workshop on block cipher modes, with 4 accepted papers on the topic. Since then, there have been numerous recent publications, adding to the literature starting in 2017 but only recently being taken more seriously.
The key takeaway is that whilst performance is great, it should not be the main goal. Cryptography is about security. Performance at the expense of meaningful security causes problems.
