They're great for attacking systems, because so many programs aren't prepared for them. Any program that uses filenames as keys (and there are many) can have this vulnerability if the input validation has a weakness.
I don't think there are any legitimate uses. They also make it unnecessarily hard to write robust shell scripts.
That's why things like upload sites usually ignore the provided file name and generate their own (unique) one, or else limit it to a very safe subset like [0-9A-Za-z_]
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -
* The slash `/` is portable as a separator.
* The filename should not be empty
* The filenames `.` and `..` are special. (in many contexts it's reasonable to exclude all components that start with a dot)
* The filename should not start with a `-`
* The entire path should be no more than 256 bytes and no component should be more than 14 bytes (widely ignored since we assume modern filesystems).
I mean it's not an issue in Python for example.
More generally, it's even harder to routinely call programs while connecting them with pipes and ensuring that the programs run in parallel. It's a pain to routinely call other programs and get results Python. It takes many many lines of Python to do tasks that are clearer one-liners in shell... and vice versa.
Python and shell are different; each are good at different things.
> Python and shell are different; each are good at different things.
I agree there. Shell is good for interactive use and throwaway scripts that you don't dare share with anyone.
Python is good for scripts that you want to actually work without supervision. (Though Python is just an example; I would recommend Deno if you are actually scripting stuff.)