Why do you think it's good to put a long command in a script, but bad to make it an alias? It sounds like you think shell dotfiles can't be managed across machines just like script files.
That isn't exactly what I wrote, but I'll still try to answer your question.
An alias is only going to be available to the current shell and it's going to be stored in memory. A script is going to be accessible to the entire system and stored on disk.
In the majority of my use-cases I require shipping software to production systems and my scripts are used to manage production services. The last thing I want to do is having to manage aliases on multiple systems ( some of which I do not own ).
To me the difference between a script and an alias is too trivial to quibble over. I'm fine putting all of my aliases into one-line scripts, if that would really make them easier to manage across systems.
My basic philosophical disagreement is with the idea of avoiding interactive command shortcuts. This essentially limits you to only using command line features you can memorize, or be willing to look them up every single time. There are too many commands, with totally inconsistent argument styles, for this to be practical.
The result is that you're only going to use a small subset of the command line's power if you limit yourself in this way.
RANT: Yes, I agree alias ll="ls -l" is a crutch. But why does 'sort' use -t for separator and -f for field, while 'cut' uses -d and -k? The famously composable Unix tools really aren't very consistent. Radically improved tab completion and documentation (vs man pages and Info) might be a start, but in the end you have to evolve new syntax.
Thank you, I can't even keep track of the option names for long enough to properly curse them. I wonder if there could be a kind of POSIX schema for similar options across utilities, such as
-o fieldseparator=,
-o fieldkeys=2,1,3
which could be used by any program whose capabilities require such a specifier, could be parsed from config files and environment variables, and aliased for reduced verbosity.
Personally - I write aliases locally that I know I don't need/can live without remotely (e.g. "vi" aliases to "vim" because sometimes I fail to get that "m" on there and I want vim but only on my laptop), I can't imagine writing "system-wide" things as an alias without losing some sleep.
I'd agree with the concept of memorizing it in theory but I'm with you that it becomes a bit too much when the tooling differences in switches from command to command can be even minimally different (something as simple as scp "-P" vs ssh "-p" is easy to forget in the moment). Yeah, I can memorize that example but everything has flags for everything and they can be vastly different (like you mentioned sort vs. cut)
Unsolicited opinion on this: she'll scripts are great for adding documentation to commands. I've got a lot of 2-5 line scripts that just remember the right commands for me.
Aliases I only use as direct abbreviations of the underlying command.
An alias is only going to be available to the current shell and it's going to be stored in memory. A script is going to be accessible to the entire system and stored on disk.
In the majority of my use-cases I require shipping software to production systems and my scripts are used to manage production services. The last thing I want to do is having to manage aliases on multiple systems ( some of which I do not own ).