As a MAC, HMAC is fine, with any of the SHA-* functions. It's even fine with MD5, even though MD5, as a hash function, is quite broken. One interesting characteristic of HMAC is that it requires no nonce or IV, which makes it quite harder to get it wrong. It's also very easy to implement (over a hash function implementation), and a straightforward implementation will even be constant-time.
Now, HMAC is defined with two nested hash function invocations, so as to provide a secure MAC when the underlying hash function is a Merkle-Damgård design (like SHA-1 or SHA-256). SHA-3 was defined so as to make that double invocation unnecessary; with SHA-3 you can simply hash the concatenation of the MAC key and the data, and that is a good MAC, while doing the same with SHA-256 or SHA-512 would fall prey to the so-called length extension attack. However, you can also use HMAC with SHA-3, it works and is not insecure.
Over long input data, HMAC has about the same performance as raw hashing, so it is quite fast, and it takes some effort to find a situation when that speed is not already more than sufficient. If you found a case where you actually need an extra boost, then there are other MAC constructions that can give it to you, e.g. Poly1305. However, they are more difficult to implement, and even more so to use properly, because they need a non-repeating nonce, which is not a simple requirement in many contexts.
That being said, most usages of MAC are, in practice, part of protocols that combine MAC and encryption. Making both safely is known to be fraught with perils (SSL, famously, got it wrong), so you would be well-advised to use an authenticated encryption mode that will do the job in a cryptographer-approved way. Usual AEAD modes include AES/GCM and ChaCha20+Poly1305. Selecting such a mode voids the question of choosing a stand-alone MAC.
Speaking of good advice, Schneier and Ferguson got it wrong (at least in the first edition of their book), in that they recommend to use MAC-then-encrypt (MAC on the plaintext, not on the ciphertext), which is exactly what plagued SSL/TLS before TLS 1.2 introduced AEAD-powered cipher suites.