Eh? That's quite the opposite to my own experience.
I know of a few widespread Perl scripts that mangle file names in Linux (for example, the rename script cannot handle newlines in file names), and bugs are common in shell scripts written by new users, but other than those, I haven't had any issues in years.
There are very few rules in Linux for filename components: must not be empty, must end with ASCII NUL (\0, code 0), and must not contain an ASCII slash (/, code 47). Length limits vary from filesystem to filesystem; aside from FAT (8.3 names), I haven't hit the limits in ages.
If you set LC_ALL=C LANG=C and double-quote your variable expressions, even Bash handles them all -- yes, including newlines -- correctly, without any problems. If a Bash script neglects to set the locale, then Bash will try and check that the file name is valid in the current locale, which is not useful; it'll barf if the name is not representable in the current charset.
Most compiled programs have zero issues. I don't even remember when I saw filename problems.
(Well, I do, but that's because I had a filesystem full of file names using different character sets. They work just fine -- the kernel does not care -- but many tools assume file names use the character set defined in the current locale, and when the exact file name is not representable in the current character set, they just skip it. The solution is to use the C locale as above, and use heuristics to guess the character set used for each file name.)
Anyway, claiming that most Linux software does not handle spaces in filenames is utter crock.