Padding oracles are relatively specific to a padding mode to be used. What you seem to be talking about is a specific plaintext oracle; a padding oracle can be seen as a special form of plaintext oracle. Such oracles can always be present if the receiver handles unauthenticated ciphertext. This is why the current focus is to use authenticated ciphers.
When we talk about padding oracles they are generally related to modes of operation such as CBC (or ECB, but yeah) and a padding scheme that extends the plaintext with padding bytes. Plaintext oracles may however be present for any mode of operation that doesn't provide message integrity.
Note that plaintext oracles are not limited to repeated characters; they are about known plaintext. If repeated messages from an adversary are allowed to be received, and the receiver handles the plaintext then an adversary may learn about the message from any leak related to the contents of the message.
The easiest way to avoid oracles is to use a transport layer protocol that uses an AEAD cipher (or at least a correctly applied authentication code such a tag generated by HMAC). Within transport security the session keys protect the messages, and if an attacker changes any protected message then the communication is shut down and a new (authenticated) session needs to be setup.
This is why cryptographers generally recommend TLS or SSH to developers. Creating a good transport layer is hard, and protection against plaintext oracles is only one reason why it is hard.
For asymmetric encryption it should be assumed that the attacker can send any message. This is because an attacker is assumed to have the public key used for encryption. The sender needs to sign a ciphertext to avoid oracle attacks for asymmetric encryption schemes.
Note that different padding modes of RSA can also be attacked if an oracle exists. Correct implementations of RSA decryption should not be vulnerable against padding oracle attacks though.
