A quick glance at the timeline here will show you that shell aliases are a popular topic. Still popular but to a lesser extent are shell functions, git aliases and wrapper scripts.

There's nothing wrong with liking aliases!

But I think that, as with everything, you should understand what you're doing before you do it.

Copypasta

When you use someone else's aliases it's typically by pasting in a whole bunch or sourcing an entire file of them. Did you read everything through and understand it? Is there something malicious in there? Is there something not-so-malicious but put in there for a joke?

Cargo cults

Some aliases you find shared on the interwebs are highly opinionated. For a trivial example, should mkdir shadow command mkdir -p? Do you know why you're choosing to do that, or is it just someone else's preference?

Recursion

What happens if one alias calls another, which calls another (or itself)?
You can often get around this by explicitly specifying an alias uses command if appropriate or by making sure the script providing your aliases is nicely ordered and commented.

I'll bet you have to take a few seconds to figure it out though.

Efficiency

alias gcma='git commit -a -m'

Surely it's more efficient to type gcma than git commit -a -m? Isn't that obvious? Well it is if you've committed it to muscle memory. Before that, there's a learning period where your abbreviation is something you have to look up or work out each time.

Predictability

If it's an alias, will you remember that the message parameter to gcma is mandatory and must be included in quotes because it's a single parameter?
If you build this as a shell function...

gcma() {
  git commit -a -m "$@"
}

...instead of an alias to include the quotes, so you can type gcma foo bar baz, what will it do if you include them a second time, or if you forget the message completely?

What if you want to pass another parameter to git commit, like --squash? You can do it with the alias there but not the function as it stands. The cleverness of saving typing the extra quotes limits your options.

When you have a long list of these shortcuts, can you predict the behaviour of all your aliases without testing them for yourself?

Availability (Local)

If you're used to using an alias for something, and you try to use it somewhere outside your terminal session, are you sure you know what will happen? An alias in a script or a cron line will either not work or do something else if it's shadowing an executable. Are you confident enough that you won't make a mistake because you've come to rely so heavily on the alias that it's second nature?

Portability (Remote)

When you use a foreign system, your aliases aren't there. If you shell into a VPS or a local container for some reason, what are you going to do? What if you've been swayed by all those articles promoting zsh and decide you want to try using a different shell?

Shadowing (between systems)

What if you don't notice that your alias isn't there but the command you typed didn't do what you expected because you've shadowed it locally? You think for a minute, pull up the man page and browse through it wondering how everything used to work and whether you're forgetful or going a little mad.

Audit trails

Looking through your shell history to find out what you did last week when you had the same problem - can you remember what to search for? Was it the cryptic alias or the full command? What, exactly, was shadowed?

Let me borrow from the Zen of Python:

Explicit is better than implicit.
Readability counts.

Mostly these warnings come down to remembering when and where you're using an alias. Aliases can be very handy, but... just be careful, ok?

Cover image (largely unrelated) from ArielleJay at morguefile.com