Hmmm... my first reaction is "troll" purely because of addressing Linus personally and in such a fashion. It's turning a huge project into "this man did something naughty" and that's just childish.
Next I read the thing and think: So there's some code in the kernel, that's not GPLv2, but is clearly marked as such. It's in a separate folder, with a separate warning that says they have separate permission to distribute those things with the Linux source. It uses the kernel firmware loader so you have to place them manually in a certain place during installation in order to use them.
The only possible, practical use of those files in there is to run that particular piece of hardware. Granted, you can't take it, modify it, distribute it, etc. but it's pretty much locked to that hardware even if you could. And the restriction merely says that's all it should be used for in one or two particular instances. Thus it's of zero interest to most people, even the programmers. Without it the device is, presumably, a brick.
They are binary blobs but CLEARLY MARKED binary blobs, and can be replaced with any number of other binary blobs or properly licensed code should they exist (which, on the whole, don't exist). If the other choice is "this device MUST HAVE a binary blob to operate" and not distributing that blob, then I'd rather have a clearly marked binary blob. If I'm worried about GPL purity, I can not purchase that hardware. If I purchase that hardware, I can (in theory) write a firmware that replaces that binary blob for everybody. The nearest equivalent I can think of is Madwifi where that situation presented itself.
I quite agree that it would be better not to have drivers that are reliant on them. But if the choice is "a pretty brick", I'd rather have the capability of working hardware that can have alternate firmwares loaded at will and thus it's only a small project ("replace this firmware") rather than having to write an entire driver from scratch. It moves the boundaries to somewhere where, say, a MIPS embedded programmer can take the firmware, write his own and keep pushing it into the kernel on module load rather than having to recompile and write every line of a new "firmwareless" driver from scratch (which may not even be possible with most such hardware).
Nobody makes you use it. It has permission to be in the kernel. It can be replaced the second an alternative becomes available. People can use, test and compare the hardware running on different firmwares themselves when they become available and choose what they want. Programmers only have to replace that single file in order to test and create their own properly licensed driver. Pedants can just NOT copy that firmware to the firmware directories, the kernel won't crash. I find no problem with someone saying "Here's a kernel without it", but I imagine adoption to be incredibly low and that it won't help out-of-tree driver development at all. Anybody writing a driver for that device will want to compare their replacement firmware with that original one and the easiest way to do that is to use the in-kernel firmware loading and thus a bog-standard kernel.
I find the Madwifi issues to be the greatest precedent and it's not easy to argue that not having access to the proprietary firmware for users actually aids development or adoption of a replacement driver. If anything, it discourages a "half-done" open source driver because if it's a choice between a "half-done" driver and nothing, people will use a half-done driver. But if it's a choice between a "half-done" open source driver and a "fully-working" proprietary one, history (e.g. NVidia, MadWifi, etc.) shows that it's the existence of a fully-working driver that pushes development quality up (because otherwise people will just use the binary blob that does the job better).
I'm more inclined to say "If you want it, make it" for such obscure devices as those listed in the firmware directory anyway, moreso than "oh, that's terrible!".