a) It's not standardized behavior amongst all of the platforms that Apache Hadoop runs
Linux, OpenBSD, FreeBSD, and OS X pick the behavior of hiding control characters in ls by default. That may not be "all the platforms that Apache Hadoop runs on," but it's certainly the vast majority of real-world deployments. The remaining important platform, Windows, doesn't deal with terminals and control characters in quite the same way, so is probably not vulnerable in any case.
In any case, the fact that the behavior isn't standardized is not a valid argument either way. Clearly Hadoop needs to pick one behavior or the other. Lack of standardization doesn't dictate that we have to pick one behavior or the other. And certainly it doesn't dictate that we should pick an unpopular and surprising behavior that almost nobody has experience with.
b) It's not expected behavior relative to the rest of Apache Hadoop
The fact that one component has a security bug doesn't dictate that the other components also need to have the same security bug. This is like arguing that we can't fix a buffer overflow in one component because then it wouldn't match all the other buffer-overflowable components.
c) It's not feasible to actually make it expected behavior compared to the rest of Apache Hadoop given the proliferation of places where raw file and directory names are printed to the console
The only places we've discussed here are ls and fsck. Perhaps there are more, but it hardly seems infeasible to change them based on what we've talked about so far. Perhaps log files are also an issue, but only for people who tail the log file of the server. And to reiterate, a security flaw in X doesn't mean we should reproduce the same security flaw in Y.
At the end of the day, this is a security vulnerability and it needs to be fixed. I asked you before: "Should the filename be able use control characters to hijack the admin's GNU screen session and execute arbitrary code? I would say no, what do you say?" I would repeat the same question again.
I understand that you have a personal preference for running without -q. However, it is not constructive to -1 a patch fixing a security vulnerability without suggesting an alternate way of fixing that vulnerability. If this stays unfixed, it will probably get a CVE number.