HMAC is sometimes called a keyed hash. The key is not part of the input of a secure hash (as CodesInChaos already indicated in the comments). HMAC is a relatively simple construct to allow a key to be used as input to the underlying secure hash. It specifically is constructed to disallow length extension attacks - although those are not likely an issue in PBKDF2.
You could use If you'd use SHA-256 directly you would have to make sure you're not vulnerable against those kind of attacks. You would basically be without the security proofs of HMAC.
KDF1 and KDF2 are KDFs/PRFs that simply concatenate elements in a certain way before entering the result into the hash. SHA-3/KMAC will (largely) be a concatenation of key and message before hashing. So it certainly can be done that way.
You should however reverse your question: Why wouldn't you use a secure PRF instead of directly using a hash?.
HMAC is relatively efficient. Inn PBKDF2 (which requires a work factor / iteration count) the small inefficiencies may actually be a benefit (a good implementation should however store the intermediate hash value of the password, otherwise an attacker may have an advantage).
Furthermore, HMAC is still considered secure, even if the underlying hash is vulnerable to certain kind of attacks (such as those against MD5 and SHA-1).
For the SHA-1 and SHA-2 algorithms I'd advice you to keep to HMAC unless you've got very strong (performance related?) reasons not to.