The assertions around short options with arguments - conjoining with other short options, for example - are actively harmful to legibility in scripts, since there's no lexical distinction between the argument and extra short options. I don't recommend using that syntax when alternatives are available and I deliberately don't support it when implementing ad-hoc argument parsing (typically when commands are executed as parsing proceeds).
tar -xf archive.tar.gz
tar -czf archive.tar.gz dir/You forgot the output filename.
The thing I like about tar is that you only need to learn two options: 'c' and 'x':
tar c somedir | gzip > somedir.tar.gz
cat somedir.tar.gz | gunzip | tar x program -abcdefg.txt
-abcdefg.txt
python scr.py -a -v
ansible play.yml -v
It gets even worse with subcommands.
sudo -k command -a subcommand -v
Agreed, which is why you shouldn't do that :-) They're a lot easier to type though. I consider short and long arguments as solving different problems: the short are short so it's easy for interactive usage (especially for common options), and the long ones are for scripting (or discoverability, especially with things like zsh's completion).
So I usually use "curl -s" on the commandline, and "curl --silent" when writing scripts.