A much more likely threat is a malformed jpg or pdf designed to exploit a decoder, in which case the executable bit is completely irrelevant. Warning the user about the executable bit protects them from nothing, unless Finder is preparing to execute the file itself. It is a warning that is always ignored, and pointless warnings only make the system less secure.
And working with multiple quarantined documents exposes more bugs.
It's not a thoughtfully designed feature. If they ever fix it I would gladly reenable it.
Its 'guess the character encoding' code also might have a 'wait a minute, this is RTF/PDF' feature.
Of course, Apple could trust its own apps, but I think they should not (why increase the attack surface?) and that would lead to complaints "why can't I tell this OS that my text editor can be trusted?".
I also think (but have no data on it) that this "open a .txt file you downloaded" check is very rare for 'normal' users. If they download at all, it is Word documents, PDFs, movies, and applications.
Now, you could hardcode a list of "safe" apps, or add some kind of "I swear I'm safe" declaration to the app's plist, but that has its own set of problems. A one-time "this seems funky to me, are you actually intending to do this?" is a simple and safe default.
But in that sense an executable file isn't any different from a non-executable file, is it? The default app for the file could do equally dangerous things with a non-executable.
Also, how many applications actually _execute_ (bare machine, vm's don't count) content? My guess is that few if any of the applications a user opens that isn't executed by finder itself is going to execute the file's contents.
That said, even the author notes that this is designed to be forked. It's not a script to run on one's own machine blindly, the idea being to exclude what is not to your taste/while demonstrating features which can't be changed inside the gui. (It's also very helpful if setting up multiple accounts.)
A shell script.