Using (plain) AES-GCM for streaming data (and, in particular, allowing the receiver to access the plaintext before it has been authenticated) breaks its security guarantee.
Yes, it will "work", in the sense that the data will be correctly transmitted if an attacker doesn't tamper with it. But plain old AES-CTR will do that, too, so if that's all you care about then you might as well just use AES-CTR. Or possibly even no encryption at all.
Allowing the use of an authenticated encryption mode like GCM, but not actually guaranteeing message integrity, just creates a trap for users who may think they're using authenticated encryption even though (because they happened to use the streaming API instead of the non-streaming API) they're actually not. A responsibly designed crypto API should not include such traps.
That said, as Squeamish Ossifrage notes, it is possible to transmit streaming data (relatively) securely using AES-GCM simply by splitting the stream into discrete chunks and authenticating each chunk separately (with appropriate associated data to prevent attackers from shuffling the chunks around). If you want to provide a streaming crypto API based on AES-GCM, that's what you should do.
Note that everything I wrote above applies just as well to any other authenticated encryption modes not specifically designed to support streaming decryption, not just to AES-GCM. That's why you're not getting answers that are specifically about AES-GCM. That said, let me try to briefly address your specific questions:
Can allowing the receiver to access unauthenticated AES-GCM plaintext compromise the AES key?
Not directly.
However, the integrity protection provided by GCM mode does reduce the attack surface (by preventing attacks that involve maliciously modified ciphertext), and it's far for impossible that some system that was otherwise vulnerable to an AES key-recovery attack (due to bugs in other parts of it) might be kept safe by the front-line defense provided by GCM mode.
For example, consider a scenario where the messages consisted of, say, streaming video, and the video codec (which is not normally considered a security-critical part) happened to have a buffer overflow vulnerability that would let a maliciously crafted video stream trigger remote code execution and thereby take over the whole system. Having taken over the system, the attacker could then do anything, including capturing the encryption keys.
Since unauthenticated AES-CTR encryption lets an attacker flip arbitrary bits in the plaintext data, such a vulnerability can be quite easily exploitable (given some known plaintext the attacker can modify). Proper AES-GCM encryption, however, protects the video stream from tampering, and thus prevents such attacks — but only if the GCM authentication token is actually verified before any of the plaintext is passed on to potentially vulnerable code.
A lot of proper cryptosystem design is about minimizing the attack surface and setting up multiple layers of defense in depth, so that errors in non-critical parts of the system cannot be escalated into actual security compromises. In that sense, giving up the message integrity protection offered by GCM mode weakens the overall security of the system by eliminating one layer of defense.
Can allowing the receiver to access unauthenticated AES-GCM plaintext compromise the plaintext itself?
Possibly. Again, this requires exploiting the behavior of the non-crypto parts of the receiving application, but it's potentially easier than key recovery.
For example, even if the attacker cannot actually trigger remote code execution by tampering with the plaintext as described above, they can still inject errors into the plaintext by flipping arbitrary bits in it. By monitoring how the receiver reacts to such errors, they may be able to learn information about the original plaintext. Proper use of GCM mode thwarts this attack by ensuring that all such errors elicit the same response: authentication failure.
Also, if the attacker can learn, through such attacks, the plaintext corresponding to some ciphertext and IV, then they can also trivially decrypt any other ciphertext with the same IV. And of course, without properly enforced message authentication, the attacker is free to choose the IV of their forged messages to be anything they want.
As a worst-case example, imagine that the receiver, upon receiving a garbled message full of errors, will emit an error containing the garbled data they failed to parse. And assume that the attacker can somehow observe these error messages. Then, to decrypt any message, the attacker can simply send a forged message with the same IV as the target message and arbitrary (e.g. random or all-zero) ciphertext. The resulting plaintext will almost surely be garbage, and will thus trigger an error, allowing the attacker to learn the plaintext from the error message. They can then simply XOR the plaintext and the ciphertext to obtain the keystream for that IV, and use that to decrypt the target message.
Will allowing the receiver to access unauthenticated AES-GCM plaintext make the system vulnerable to active forgery attacks?
Yes.
There are plenty of real-world attack scenarios where the attacker isn't interested in decrypting some captured data, but simply in causing the receiver to act based on some forged data of their choosing. And often enough the attacker might not care if the forgery is detected after the data has already been acted upon.
In some cases, e.g. if the only thing the receiver is doing with the unauthenticated data is saving it to a temporary file, it may be possible to securely roll back the system to a safe state when a forgery is detected. But often that's not the case, especially (as noted above) if the data is fed to a subsystem that might have potentially exploitable bugs. In such cases, once the malicious data has been processed and the system has been compromised, there's no way to undo that.
(I believe that's what Squemish Ossifrage's allusion to the death penalty was about. Just as you can't just say "oops, sorry, didn't mean to do that" and un-kill a person after they're dead, you also can't un-compromise a compromised system after it has been taken over and all its secrets have been leaked. You might be able to reinstall the system from scratch, but you can't get the compromised data back.)
If you're not going to verify the authentication tag before allowing the receiver to access the plaintext, is there any point in using AES-GCM in the first place?
I know you didn't actually ask this as such, but I wanted to answer it anyway. And, in my opinion, the answer is a clear "no."
The only advantage of using AES-GCM instead of plain old AES-CTR is that GCM provides message integrity protection, and thereby thwarts active attacks involving message forgery or tampering. If you're not going to actually make use of that protection, you might as well just use AES-CTR. At least then you'll know that you're vulnerable.
