Why don't we use Blowfish if it hasn't been cracked? Since Blowfish is old, well-audited, and has no published attacks, why are we using AES instead? I know that Bruce Schneier said that Blowfish is insecure and told people to transition to Twofish, but why? AES has many vulnerabilities, such as padding oracle attacks and power-consumption analysis, but Blowfish doesn't have any well-known issues. And Blowfish can take a key up to 448 bits, which is larger than AES's 256 bits. Is there something I am not understanding? It's been under public scrutiny for the longest with the least issues.
Perhaps it is because of Blowfish's small block size?
Context: Is it safe to use Blowfish to encrypt strings of less than 30 characters?
Why don't we use Blowfish if it hasn't been cracked?

The reason is well-known, it has 64-bit block size and therefore it is vulnerable to birthday attacks. This is done for HTTPS and for more information see sweet32;
$$\text{Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN}
$$

Is it safe to use Blowfish to encrypt strings of less than 30 characters?
If I don't use it for HTTP, just for storing small strings, is it still insecure?

There is no problem. GnuPG made a recommendation for Blowfish;  Blowfish should not be used to encrypt files larger than 4Gb in size. If you want to use a block-cipher from Bruce Schneier use the successor, the Twofish algorithm, as he said.
This recommendation 4GB makes $\approx 2^{33}$-bytes therefore, they recommended using at most $2^{30}$ blocks of encryption under the same key. With the birthday probability if you encrypt $2^{30}$ blocks you will have
$$(2^{30})^2/2^{64}/2 = 2^{60 - 64-1} = 1/2^{5}$$ probability of collision. This is still a high probability in the attacker's advantage.

What is Sweet32 in short:
The attack performed on the CBC mode of operation where the encryption is $$c_i = E_k(m_i \oplus c_{i-1})$$ wiht $c_{-1}$ is the nonce for the CBC.
Once one encrypts $2^{n/2}$ blocks with one key by the birthday attack we expect a collision on the ciphertext with 50% probability that can be observed by an eavesdropper. This means that $c_i = c_j$ with $i \neq j$ is observed. Since a block cipher is a fixed permutation under a key this implies that the inputs of $c_i$ and $c_j$ must be the same;
$$ m_i \oplus c_{i-1} = m_j \oplus c_{j-1}$$ with changing the side of the values we get $$m_i \oplus  m_j = c_{1-1} \oplus c_{j-1}.$$ That is the eavesdropper knows the x-or of the two message blocks.

A short note padding oracles;
Padding oracle is first described by  Serge Vaudenay in 2002;

Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS

years later real attacks are performed. Vaudenay applied it to RC5 in CBC mode, and it applies to any cipher that uses CBC mode as long as the server sends the padding-fail as an error. With the padding oracle attack, all messages can be revealed since it is a decryption oracle. Encrypt-than-Mac will prevent this attack.

Update for the comment;
It turns out that OP has X/Y problem; the short string is a password then the obvious choice is the well-known solutions like the argon2 which is the password hashing competition, winner. It has two modes;

Argon2d: is faster and uses data-depending memory access. Data dependency immediately enables side-channel. This is suitable for cryptocurrencies and applications with no threats from side-channel attacks.
Argon2i: uses data-independent memory access and this is preferred for password hashing and password-based key derivations.
If you are not sure about which one to use then you can use the combined mode Argon2id.