I think the idea is that in scripts you should use the full name for maximum clarity and self-documentation; in your own terminal invocations, be as terse as you want.

That is precisely the idea. The verbose names are self-documenting. You need documentation (names, types, comments, etc.) when code will be reused and read and altered at a later time.

Interactive use is different. It is write (and tweak) then use once. You never write comments in the interactive terminal. For interactive use you have aliases, plenty of them.

One reason for that is that other people may have different aliases set up, so you cannot count on your aliases working everywhere. Yes, that also means the default aliases, which may (although very rarely) change from version to version.

For PowerShell ISE there was an extension that automatically expanded all aliases, I believe for the current language server there may be similar things. If all else fails, a PowerShell script can do that as well, since PowerShell exposes its own parser in its API, so a script can easily introspect itself or another script.

If you're working on a shared project where people might care, I usually have the [PSScriptAnalyzer][1] just auto-correct any aliases dynamically for me in my IDE.

If you're just doing a quick one-off or interactively, then who cares! Crack on with your incomprehensible one-liners!

[1]: https://github.com/PowerShell/PSScriptAnalyzer

Powershell gives the best of both worlds: readable command names in scripts, and simple Bash-like shortcuts when you type stuff in the terminal.

Is this really the "best of both worlds" or does this just double the number of commands you have the learn?

Since you don't have to learn the aliases, you can use the full command names in the interactive shell, it doesn't double anything.

Last I heard (and I haven't had direct visibility into this since about 7 years ago) aliases are preserved between versions for backwards compatibility, but you shouldn't use abbreviated parameter names in scripts because there's no guarantee that they won't become ambiguous if more parameters are added to a command.

That is true; but since the aliases and parameter names are discoverable with introspection, if you are writing a script you can have a tool which expands them all to their full name if you want that.

That said, the PowerShell team do care about breaking backwards compatibility, so this risk is more likely in a 3rd party module than in the PS main cmdlets.