Yes, this idea is good, even though it's usually considered with only one key from which you derive all your following keys.
The "some sort of hash" you describe here, actually is commonly referred to by the name of "key-based key derivation function" (KBKDF) with the most famous instantiation being HKDF, which will also replace the TLS specific counter-part in TLS 1.3.
As for why one doesn't actually use the "cycling idea" your propose here, this has two reasons: a) You have to keep a lot of secret keys secret if you want to have a large $N$ and have $N$ independent keys and b) this solution is worse than simply hashing all $N$ keys in one go (combined with some identifier to ensure uniqueness) and use the derived value, because if only a portion of the keys (i.e. one) is leaked, the corresponding follow-up key is in danger whereas with a full hash nothing bad happens because there's still enough entropy left.
As for why this sort of key-derivation is useful:
- Backward secrecy. If your current encryption keys get leaked, an attacker can only predict the ones you'll use in the future but can't recover the old ones.
- Key rotation. Rotating the keys limits the number of plaintext-ciphertext pairs an attacker can obtain under the same key which is crucial for most cryptanaltic attacks on block ciphers.