Because a container is not the same as an actual full OS installation. Running a container is great if the application in question is kept within the same container type environment (aka staying on ubuntu 18), but when you're going from, say, ubuntu 18 to 20 for a container, the application itself might not know the new environment and will run into errors. Likewise, if you're trying to do a dist-upgrade within the container itself, there's a lot of variables that could go wrong. Plus doing an upgrade is always more complex and can run into issues.
I, personally, am a firm believer of anything productive that the underline OS needs upgrading to the next major version would be a whole new server and just migrate things over. More work, probably, but it saves you headaches from having to deal with a upgrade that might or might not work.
Can you try updating the container anyways? Sure, no one's going to stop you, just know that it's not a supported method for Plesk so make sure you have backups that you can roll back to.
Or you can do the safe route, which is what I always do, and spin up a new server and use the plesk migrator to migrate it over.