The problem is for other contracts that want to use upgradable contracts - before you could be sure/analyze correctness but now you need to consider the underlying contract's implementation can change in arbitrary way, it's outside of your control, ie. if the upgradable contract you're calling is hacked it can turn malicious towards your contract - something you didn't have to worry about before.
I don't think this functionality is anything new, it's just a design pattern. As for safety, you're absolutely right. Best practices dictate that when calling other contracts, you should mark the code as untrusted, and treat it as such. It's somewhat analogous to running untested dependencies, and stipulating in your requirements that the latest version of those dependencies should always be deployed.
It's not new (if we're allowed to say that anything in system created less than 3 years ago can be "not new") but the core functionality (delegatecall opcode) was added to support linked libraries. Delegatecall's abuse to use it for "upgradable contracts" is relatively new, the opcode was not designed to handle this "pattern", it's somehow undesired consequence of introducing it that it can be abused in this way. Noting more than that. Really, I don't think most people realize what it actually means and what can and cannot be altered in "upgradable contract".
