What are the benefits of using AEAD algorithms as MAC I've seen in 2 places where NIST acknowledge the possibility of using AEAD algorithm for MAC (e.g. page 7 section 5.2 of GCM spec, summary for LAEM on page 6 of LWC status report).
And I see 2 problems with this:

An AEAD algorithm requires a nonce - something that doesn't fit well into the interface of $\text{MAC}_K(M) \rightarrow T$.

Most (and the correct) API for AEAD implementations (e.g. Web Crypto, Apple CryptoKit) receives input all-at-once - they are not progressively updated.


On the other hand, HMAC has several more application than authenticating messages - HMAC_DRBG, HKDF, to name a few. And they seems to be specifically instantiated from HMAC and cannot use other MACs, whether artificial like GMAC or associated with the algorithms they come with such as KMAC from SHA3/Keccak or keyed BLAKE2.
So to summarize, MACs derived from AEAD: 1) needs nonce, 2) needs different API (init-update-final) from that of AEAD (all-at-once), and 3) lacks usefulness.
So the questions:

Is there any benefit using an AEAD as a MAC (edit: specifically as a building block in constructs that expects one that behaves like a PRF such as HMAC) other than &quot;it reduces code/circuit size&quot;?

And what is (or was) NIST thinking when they acknowledge(d) using AEAD as MAC?
Think about 2 special cases when using AEAD:

Some confidential data but blank associated data
Some associated data, but blank confidential data

In first case what you get when using AEAD cipher (e.g. AES-GCM) is just Authenticated Encryption, as there is no associated data.
In second case what you get when using AEAD cipher (again, e.g. AES-GCM) is essentially a MAC - there was nothing to encrypt, and what you actually did was calculation of authentication tag over associated data.
BTW, &quot;What are the benefits of using AEAD algorithms as MAC&quot; and &quot;What is (or was) NIST thinking when they acknowledge(d) using AEAD as MAC?&quot; are actually two different questions. I hope I answered the latter.
EDIT:
If you look at MAC algorithms like Poly1305, Poly1305-AES or CBC-MAC, they also use nonce/iv.