There are a few things to take into account here.
Why is this not required by keyservers to ensure that only the owner of the private key can upload … ?
The main problem with a malicious key is someone posing as an identity he is not allowed to use. The uploader of the key would hold the private key, so we didn't gain anything here.
On the other hand, it is sometimes useful that a third party can upload a key.
… only the owner of the private key can modify the public key on the server?
This already happens. You can't eg. add an identity or a subkey to a key unless you have the private part of the main key. Not only the keyservers, openpgp clients would detect that such key is wrong, too.
However, it is possible for anyone to add a signature to your key. This translates to a vouch that the key belongs to whom it claims (eg. they checked your passport and it states the same name as your OpenPGP key). This is a crucial part of the PGP web of trust model (even though, if not indicated otherwise, it is educated to send the signed key to the user instead, rather than publishing the signed key directly).
…remove the public key?
To a point, it already does so. Note that the keyservers form a distributed system, with the many servers syncing their different keys. Thus, if a keyserver completely forgot about a deleted key, it would be readded a few hours later when syncing with another server. Thus, what we need is a deleted flag that only the key owner can set.
This already exists, with the name of revocation certificate.
Note also that the goal of the keyservers is to hold many keys (so you can find the one you need), not having trusted keys or providing any kind of insurance over its contents. You are expected to use the Web of Trust for that.
A closed keyserver that functions more similarly to what you propose is the debian one: https://keyring.debian.org/ It does so by adding a human into the process (the Debian Account Managers) in order to perform some steps (most importantly, the upload of new keys).