I think you answered you own question:
Is this a consequence of the fact that these systems are designed to work with a CA hierarchy?
Yup. In the X509 Certificate model, Root Certificates (or "CA Signing Certificates") have the basic constraint
CA:True which allows it to sign other certificates. By putting the root cert into your trust store, you automatically trust every cert that they sign (and certs signed by subCAs signed by that root CA cert) so with only one cert in your trust store, you automatically trust a whole hierarchy of CAs and certificates - even ones you've never seen before. Otherwise you'd have to manually add every single non-CA cert to your trust store and it would very quickly become a memory and disk space hog, and the problem of how to trust a new certificate that you've never seen before becomes a lot more complicated.
As pointed out by @JonathanGray in comments, a self-signed cert might be what you're looking for since it's both a root CA and an end-user at the same time. Though it doesn't solve your original problem of having to do multiple setup steps.
I'm not aware of any technical reason why you would be blocked from putting a non-root cert into your trust store, except that it would have to be programmed to look for that. Since that use-case only makes sense in dev environments I'm guessing that most software vendors wouldn't bother to spend time writing that code.
In more detail, the trust-store step of certificate validation works like this: suppose you are validating an SSL server cert, look at the CA who signed this cert and see if they are in your trust store, if not, look at the CA who signed that and see if they are in your trust store, and so on until you either find one, or hit the top of the chain. Most software probably wouldn't bother looking for the end-user cert in the trust store just because you're wasting the runtime of an expensive search on something that should never happen in a production system anyway.