First of all a note about terminology: semantic security is a property of a cipher; it is not a method or algorithm, so "semantic security" cannot protect anything. Of course, if a cipher is semantically secure then it should protect against key recovery, as key recovery would directly lead to plaintext recovery. If full plaintext recovery is possible then obviously it is not semantically secure.
A block cipher is a algorithm (a primitive) that can be used to create a semantically secure cipher. The block cipher itself should protect against key recovery. As long as you don't re-use the key anywhere else in the scheme - and that's a sensible default - then you don't need to provide additional protection. This is probably why it isn't mentioned specifically.
Now if you don't use a block cipher at all (a stream cipher may not) or if you use the key directly to create e.g. an authentication tag, then yes, you need additional protection against key recovery.
Beware that some schemes introduce new data elements that may act as keys in the scheme. If that's the case the construct should of course provide protection against recovering those keys. This is e.g. the case for the value $H$ - the hash-sub key - in GCM mode.
Note that the authentication tag is calculated over the ciphertext in GCM mode, so the cipher would still be semantically secure even if that key gets leaked even if the message authentication property would be broken. This may still lead to loss of confidentiality due to plaintext oracle attacks, but that's outside the definition of the cipher itself.
The cipher would be considered semantically secure because CTR mode - the underlying encryption mode of GCM - would still provide semantic security.
