You've described an $n$-of-$n$ threshold encryption scheme by nesting: there are $n$ shares of a secret key, and it takes all $n$ of them (in the right order, so I hope you labeled them) to recover the plaintext. Similarly, there's a simple $1$-of-$n$ threshold encryption scheme by concatenation, which is what, e.g., OpenPGP uses for multiple-recipient messages.
What neither of these handles is $k$-of-$n$ for $1 < k < n$; e.g., $2$-of-$3$, where you want to ensure that either
- you and your solicitor, or
- you and your mistress, or
- your mistress and your solicitor,
can collaborate to recover the secret, but none of them individually can (and definitely not your husband).
Obviously, it is possible to compose nesting and concatenation to have the same effect—do $1$-of-$3$ where each share is a $2$-of-$2$ threshold system itself, for instance, like the list above—but there is a bit of a combinatorial explosion of overhead this way especially when $k \approx n/2$ so that the overhead grows as the central binomial coefficients.
In contrast, Shamir's secret-sharing scheme costs only $\log_2 n + b$ bits per share of a $b$-bit secret no matter what the threshold $k$ is, for a total of $n \log_2 n + n b$ bits of overhead, or $k \log_2 n + k b$ bits of storage to recover the secret.
Note that secret-sharing schemes are almost never what you want in practice (except, perhaps, for revealing deathbed secrets).
For example, if you jointly control a bank account, and you want to ensure any transfers out of the bank account are authorized by two of three signatories, it is a bad system to use a single signing key split up with a secret-sharing scheme—if you do that, then every time you sign a check, you necessarily reconstitute the single signing key, and whoever owns the computer on which you reconstituted it now has unilateral power to sign checks.
It is generally better to use threshold signatures, the simplest system of which is just the concatenation of signatures by distinct authorized parties.
