In secure transport protocols, the authentication tag (i.e. MAC value) is usually calculated with a session key. This session key is not linked to the data that is send, it is just used to protect the records within the transport protocol. Hence after processing the records, the tag is stripped off to retrieve the actual data that was send. Furthermore, after the session ends the session key gets destroyed - it is often not available at application level.
So although the authentication tag does protect the data while it is "in transit" it doesn't offer any protection afterwards. This is not because the MAC algorithm is not strong enough, it's just that the authentication tag and session key are not available anymore to validate the integrity/authenticity (as explained above). HMAC's are actually one of the most reliable schemes out there.
As example take the various TLS libraries. I don't know any where the TLS records or the session key is passed on to the application layer. TLS always protects the data with an authentication tag regardless.
To protect the data outside the transport protocol it is required to add protection in an application level protocol. For instance it is possible to send enveloped messages using the Cryptographic Message Syntax. For this long term keys are required. It is certainly possible to use a MAC to do add integrity to application level messages for long term storage.
Signatures are more common though. This is because a MAC requires a shared secret; symmetric cryptography is cumbersome when it comes to key management between different parties.
As it is now seems common to add a tl;dr: It's not so much the properties of the MAC rather than how it is used within a protocol that makes it just protect messages in transit.