It is possible to do this, but public key algorithms are typically substantially slower than most MAC algorithms, which tend to be based around hash functions. RSA specifically also results in signatures that tend to be around the size of N, which is also much larger than a typical HMAC function (3072 bits versus 256 bits for 128-bit security).
For comparison, on my three-year-old laptop with OpenSSL 3.0, I can do 28,416 3072-bit RSA verifications per second, 9954 Ed25519 verifications per second, and 85,395 16KiB HMAC-SHA-256 operations per second. This actually understates the performance of HMAC-SHA-256, since most signed requests are actually much smaller, and on newer machines SHA-256 is extremely fast since it's accelerated in hardware.
For making a small number of requests, this isn't a problem, but when your server is processing large numbers of requests, this can matter quite a bit, since you want the bulk of the expense of the operation to be performing the user operation and not authenticating it.
It is also substantially easier to encode and decode an HMAC value than a signature. Typically, one just uses something like base64 encoding. Digital signatures typically use large integers, which must be written in some endianness (which one matters), can use multiple integers (how to encode them and separate them matters), and often require validation (padding for RSA, point verification for ECDSA). In addition, private key operations that are online can be subject to timing attacks, which most hash functions are impervious to. Because HMAC is substantially simpler, it is much more likely that people will use a secure and correct implementation on both the client and server side, which is a huge selling point, considering that overwhelmingly security problems stem from implementation or protocol errors and not algorithms which have been suddenly broken. (People do still use insecure algorithms, but usually there is plenty of advance notice that the algorithm is weak and alternatives should be considered.)
In many cases, the risk of compromise can be minimized by limiting the lifetime of the token. For example, requiring people to constantly rotate the credentials means that if the database is compromised once, the credentials will soon be useless. This can easily be achieved with automated means in software, so the burden of doing so is often minimal.
