Credential Guard is intended to protect derived credentials that can be used to move laterally between devices. This turns out to have a real practical impact to attacks because it increases the level of sophistication required. That doesn't make it perfect, but it does make it pretty good.
In order for Credential Guard to protect credentials it needs to understand how the credential is to be used. That limits it to credentials used for Windows auth. There's no way to reason about what any other type of generic credential is used for, so therefore it can't know how it can be used, and therefore can't protect it. Credential Guard could simply block retrieval of passwords, but doing things like that has a tendency to reeeeeally piss off app developers (and users) that listened to Microsoft and are doing the right thing and not rolling their own credential caches because it breaks something that's considered relatively safe.
But again, in this case though cached Windows credentials are protected. You don't get access to the raw credentials; you only get a ticket to the remote service on behalf of those credentials. You can only access that one service -- you can't take that ticket and access whatever you want. This breaks lateral movement. This is also why unconstrained delegation doesn't work.
Whether this is acceptable or not is a matter of whether you think single-sign on is a good thing. You don't get SSO if a user can't request a ticket to a remote service, and there's no way to distinguish between a real user running as some account, or an evil user running as some account.
For completeness there's also the logon cache which is used to validate interactive logins, but that doesn't store raw credentials either. All it stores is a hash used to validate incoming passwords.
