Why is the subhash key (H) of AES-GCM defined as such? From what I've read in section 5.3 of NIST 800-38D it states:


  The hash subkey, denoted H, is generated by applying the block cipher
  to the “zero” block.


In serious crypto J.P Aumasson describes the implementation of it as H = AES(K,0) for a single block of zeros, hence no block chaining mode, hence no IV as I understand it. Therefore the mapping between H and K should be universally constant.

The book notes:


  In GCM, GHASH doesn't use K directly in order to ensure that if GHASH's key is compromised, the master key K remains secret. Given K, you can get H by computing AES(K,0), but you can't recover K from that value since K acts as AES's key.


If the mapping is universally constant wouldn't it be the case that this could be pre-computed and available somewhere? (I wanted to say rainbow table here, but that probably doesn't quite apply based on what I read in this response)

So is the strength just that storing this permutation space for later indexing is thought to be too large? Or is there more to it that what I laid out?
In GCM, GHASH doesn't use K directly in order to ensure that if GHASH's key is compromised, the master key K remains secret. 


Actually, there's not why GCM was designed the way it was (it may be an effect, but not the reason).  Instead, the reasons were:


To allow provable security (based on the assumption that the block cipher was a secure keyed random permutation).  If we used $k$ as both the block cipher key, and used as an input to compute the tag, we need to make additional assumptions on the block cipher.
Because of the size mismatch; $h$ is 128 bits, $k$ is (at least, for AES) is either 128, 192 or 256 bits.  Yes, one could select an arbitrary section of $k$ as your $h$, however, that seems a bit, well, arbitrary...


In any case, to answer the question you did ask:


  If the mapping is universally constant wouldn't it be the case that this could be pre-computed and available somewhere?


Not really, the effort of pre-computing such a table would be at least $O(2^{128})$ operations; we believe that is infeasible for anyone, even as a one-time effort.  And, generating a rainbow table doesn't decrease this effort any; it just makes the generated table smaller...