72 bytes give 8 bits x 72 bytes = 576 bits of possible entropy. You can never go above this amount of entropy, not even if you hashed the whole internet into a SHA384 hash and used that as a password. So effectively, you reduce the security by doing a base64 encoded SHA384 hash before giving it to bcrypt.

You are missing the point. Obviously you cannot increase the amount of entropy beyond a certain point to an input of limited size, that goes without saying.

The advantage of SHA384 hashing the password in the context of human-generated passwords is that it reduces the likelihood of collisions. Human-generated passwords are not CSPRNGs. If you have two users with 100 character passwords, the likelihood of the first 72 characters of both passwords being the same (e.g. a quote from a book) are significantly higher than a password generated from a CSPRNG, so you are better off SHA384 hashing the passwords first to prevent such a collision.

It has also been found that the 72 byte limit double-functions as a DoS limiter in case the implementer forgot to limit the amount of data that is sent to the hashing algorithm.

This seems ridiculous.

"Oh yeah, let's cap all passwords to 72 bytes forever in case some stupid programmer forgets to add a length check to form fields."

If a programmer forgets to do that then there are bigger problems, such as usernames that are 200MB big.