The most commonly understood meaning of 'asymmetric' in this context is that there are two different keys used, one for encryption and one for decryption, as opposed to symmetric cryptography where just one key is used for both encryption and decryption.
Presumably the 'symmetry' is seen in the diagram of the process: plaintext, plaintext and key, ciphertext, ciphertext and key, plaintext. There is key symmetry, one could say. The 'asymmetric' process is: plaintext, plaintext and public key, ciphertext, ciphertext and private key, plaintext. There is key asymmetry because on one side there is the public key and on the other there is the private key.
Here is a quote from this answer https://security.stackexchange.com/a/70458/257850:
"This is the path used when proving the encrypted data hasn't been tempered with, commonly known as a digital signature[1].
The part the diagram leaves out is that the commonly accepted technique for digital signatures is to use a hash function, like SHA-256, to represent the data, then sign the hash. It reduces the amount of data being transmitted and reduces the amount of data available to an attacker to reverse engineer the private key."
This means that 'encrypting' a message with the private key, besides being better called 'signing', comes with the danger of providing clues publicly to potential adversaries as to what your private key is. This is especially a problem if this is done on many occasions with the one private key. By instead deriving a hash from the message, and encrypting (signing) that, you reduce the amount of clues given.
Referring to signing with a private key as 'encryption' with a private key could lead to someone thinking that a secret message is safe because it was 'encrypted'. In other words, there is more than one kind of encryption, and some kinds do not provide secrecy, and ironically, using a 'private key' is the way to inadvertently make your information public. Indeed, one has less privacy than before. Not only is your message available to be seen by all, but you have drawn attention to it by attempting unsuccessfully at encrypting it properly, and you have signed your name to it, letting everyone know exactly who sent it and resulting in your having no plausible deniability anymore.
It's counter intuitive, perhaps, for the layman, that the last thing you should do with private information is to encrypt it with your private key. The layman might not understand that the key is called 'private' because it needs to be kept private, and that is does not make a message private, but rather it signs the message robbing you of plausible deniability (although if you say that your private key somehow got stolen or accidentally was revealed to others well before you signed that message you might get back a little deniability).
That's one reason not to call signing with the private key, 'encryption with the private key'.
This answer (https://security.stackexchange.com/a/159289/257850) has this statement:
"[S]ignature is not encryption with the private key -- not even for RSA, where there is enough similarity in the mathematical underpinning that it is dangerously appealing to think this even though there are vital differences in the actual schemes and trying to interchange them leads to very bad results, and totally completely not at all for other algorithms like DSA and ECDSA."
I take this to mean that mathematically it sort of, at least, is true that signing with the private key is encryption with the private key, but in the software implementations in real life, it is a terrible idea to think of at this way, let alone say it out loud when employees, or anyone else you are entrusting your data to, are around.
