As for why anyone might feel aggrieved about replacement of core Unix services, my mind immediately drew a (possibly unfair, but emotionally comparable) parallel with systemd.
Why not? I would.
One could sometimes use find(1) of course, but it has different semantics and output to ls unless you jump through some very silly command-line hoops that will make you say "should've just used ls".
As for the stat(1) program, which might be an alternative for individual files, it is not standardised, is not portable, and is in fact totally incompatible between GNU coreutils and BSD userland (including Mac OS).
[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls...
"As with many of the utilities that deal with filenames, the output of ls for multiple files or in one of the long listing formats must be used carefully on systems where filenames can contain embedded white space."
POSIX is such a system. If you try to parse the filenames output by ls, it will break when you encounter a filename with whitespace in it. Use a shell glob instead—it will actually work right.
In the meantime, I recommend you try deleting /bin/ls from your system and then filing bugs against everything that breaks.
touch 'file with spaces'
for file in $(ls); do
rm -- "$file"
done
Now do this:
touch 'file with spaces'
for file in *; do
rm -- "$file"
done
ls -Q
touch 'file with spaces'
for file in $(ls -Q); do echo "$file"; done
"file
with
spaces"