First of all, it is possible to combine the Galois multiplication by using modular exponentiation. This does make it possible to use parallel processing during encryption and decryption, even if the overhead for the modular exponentiation will somewhat diminish any speed gain.
Furthermore, if you just want to decrypt the ciphertext then you can do that without calculating the MAC value, by simply using counter (CTR) mode with a carefully calculated initial counter block.
However, the value of GCM is that it is an authenticated mode, for which you need to verify the authentication tag to get the integrity/authenticity that the AEAD cipher promises. In that sense it may not be all that useful to decrypt only parts of the ciphertext: you will have to process all the ciphertext bytes for the MAC calculation anyway.
Still, if you just need a particular part then it could make sense; you would need fewer AES calculations. It is also possible that you would have fewer memory requirements. The lower memory requirements are not present if you can put the plaintext in the same buffer as the ciphertext though when using in-place decryption.
All these arguments do however stumble around the major issue with your question: "Could anyone explain how the requirement of the GMAC doesn't nullify the usefulness of being able to decrypt a message starting from anywhere in the stream?". The truth is that this particular property of CTR IS largely nullified by GCM or any other AEAD construction that uses it.
CTR has many other advantages though: only AES in encryption direction required, no padding required, easy to pre-calculate the key stream, parallel processing, no requirement for an unpredictable IV and the ability to perform an inline encryption of the final value within GMAC.
Actually, a lot of higher level API's simply provide a one-shot encryption and decryption methods for AEAD ciphers such as GCM, and if you use those methods then the ability to decrypt from a certain offset is definitely nullified.