Please clarify that. Does it matter? Are all USB devices field programmable? The term 'field programmable' means easy to alter away from the factory with simple portable equipment.
an EEPROM can be reprogrammed by altering the voltages and inputs on the chip pins. So too, in fact, can an EPROM. the Difference is that you cannot erase an EPROM electrically. You can program a blank EPROM chip as desired, however you cannot, electrically, erase them. (Typically they are erased via UV Light exposure).
That seems rather critical given this exploit/vulnerability. If the chips used for the firmware on a USB Flash Drive are EPROM than they cannot be reprogrammed via the USB plug. Even an EEPROM is tenuous and as we can see in the source code, examples, and documentation, the vulnerability and particularly, taking advantage of it, is very dependent on the model, manufacturer, and even capacity of the drive. the firmware storage of the 8051 is not built into the IC, and needs to be hooked up to it by sending traces to the appropriate pins on the chip. The microcontroller then runs that code. the exploit them relies on the 8051 having direct access to the programmability of that separate chip, and that separate chip being electrically erasable. This is why the concept code can only work on a single model, manufacturer, and capacity of drive (Patriot 8GB SuperSonic). It also won't work if the drive supports USB3 (since that typically uses a different embedded microcontroller to begin with)
Granted, there is, to date, much speculation about would may or may not happen. But just imagine the following. Many devices do use the chip in question.
None of the USB Drives I've taken apart (broken ones, of course) appear to use the controller. Since it is a Memory controller USB interface it is not going to be present except on Flash Drives and composite devices. It is not used in USB keyboards, USB Mice, USB network adapters. It's not even used on external hard drives. And even within Flash thumbdrives, only a subset of devices actually use it. This is demonstrable by simply taking apart a few such devices and identifying the chips within.
An gang of thugs are organized to break into a IT deportment and locate the stock of USB drives that are being inspected by the staff during the day. Maybe an inside job. The thugs zap all the USB devices they find with a portable device which does the chip mentioned. Some USB devices are burnt out because they had other chip sets. Next day the IT department does not see any trace of a break in. They have no idea why some USB sticks went bad overnight. What happens next?
Yes, pure conjecture. Now should we just wait and see if it happens? 
Thus my reasoning in my post in the other thread which I linked, which was that this would only be particularly useful for malicious uses when you knew exactly what hardware was being used- what flash drives, what OS on the system, etc- thus penetration testing or for trying to get into specific computer systems.
The problem with your hypothetical is that it is dumb. The thugs already have physical access to the systems that they would be intending to infect. using a special device to basically infect USB drive firmware in order to allow those USB drives to pretend to be keyboards on host systems and do.... something?... is pretty useless considering they
already have physical access to those systems they want to infect.
Your entire hypothetical completely contradicts your original assertion that "It is not just another hacker trick" by providing an example in a context where it is exactly that.
More...
EDIT: Some links to sourtce code.
http://blog.lumension.com/9442/unpatchable-badusb-malware-code-is-now-publicly-available/
http://www.extremetech.com/extreme/191467-badusb-returns-hackers-publish-code-that-could-infect-millions-of-usb-devices
http://www.securityweek.com/badusb-code-published
These are recent posts, which may suggest this is not the code mentioned artier. Otherwise, why publish three months after the demonstration?
Those articles link to the same github repository that I already linked, Created on Sept 26th. The articles themselves- which if I may be so bold to say that you don't appear to have read since it answers your question- are clear as to why the code was released after the original Black Hat conference.
Previously, it was demonstrated by Karsten Nohl and Jakob Lell at the Black Hat security conference in Las Vegas, showcasing that the firmware of USB devices made by Taiwanese electronics manufacturer Phison could be injected with undetectable, unfixable malware.
Crucially, however, Nohl did not release the code used for the exploit at the time. But Caudill and Wilson have subsequently made the decision to release fuller details about BadUSB at the recent DerbyCon hacking conference in Louisville, Kentucky.
“The belief we have is that all of this should be public. It shouldn’t be held back. So we’re releasing everything we’ve got,” Caudill said to the audience at DerbyCon. “This was largely inspired by the fact that [SR Labs] didn’t release their material. If you’re going to prove that there’s a flaw, you need to release the material so people can defend against it.”
It's notable that even in that original conference, the "exploit" demonstrated- like the source code now made available, only works on a very specific brand of Microcontroller (Phison). and it only works in very specific circumstances- the core issue is simply that, if the chip is traced to it's firmware chip in a specific way, and that firmware chip is an EEPROM, than the microcontroller can be instructed to electrically erase that chip and reprogram it, thus revising it's own firmware.
-If that chip is not an EEPROM, nothing happens, and the existing firmware would remain.
-If the microcontroller is not connected to the EEPROM firmware chip in a specific way, nothing happens.
-If the microcontroller is not a 8051, nothing happens.
-If the EEPROM chip containing the firmware is larger than 200K, nothing happens.
-If the EEPROM chip containing the firmware is smaller than 200K, nothing happens.
-If the Microcontroller is not manufactured by a specific taiwanese manufacturer who accidentally left development EE traces active, nothing happens.
And the end result? Even in a case where the chip can be exploited.... It can only pretend to be other USB devices. It cannot arbitrarily run code on the host system- only on the device itself. It cannot connect to the internet itself- because it has no network connectivity. In general all it can do is pretend to be a keyboard and perform a specific sequence of pre-programmed keyboard input. In the Blackhat demonstration for example the device was programmed to input a specific sequence of keystrokes which would open Internet Explorer and take it to a compromised, exploited web page. That could only work when you know the specific system.
Fundamentally what it boils down to here is that despite your assertions otherwise this really is just "yet another hacker trick"; You illustrated that particularly well in your (arguably contrived) example. It is something that those looking to harden a company network and protect company data will want to explore, but only if they haven't already hot-glued all the USB ports on the company systems. eg to expound on your example somebody who wants to get into a company's database for presumably nefarious purposes might befriend an employee. After learning about the company's system and that employees particular workstation, they might engineer a specific USB flash drive- one that they know can be exploited in this manner and which they can successfully purchase, test, and verify works as they intend. They could then infect their 'friend''s PC with something that prevents all mass storage devices from working. Knowing that employee only has one flash drive, the nefarious hacker can loan them the exploited one. It connects as both a flash drive- allowing the employee to borrow the drive to copy his work files, as well as as a keyboard. When files are copied from that drive it will activate a sequence of keystrokes that would activate a hidden browser and launch it to a website that the nefarious hacker setup specifically the take advantage of perhaps unpatched exploits in the browser version used at the employee's company. It would then install a backdoor and broadcast it's address to an IRC server that the nefarious hacker setup for that purpose, and the hacker can then instruct the employees system to connect to a server IP they have listening for connections and then access the system via remote access.
The fact is, however- in this example the entire operation is absolutely destroyed by any prudent security on the company's end.
-Many companies disable, uninstall, or block USB devices entirely (hot glue in the USB ports of company systems, for example).
-Unauthorized systems on the network are typically not leased an IP and thus are unable to access the internet (eg laptops brought from home, iPods, Wifi routers inconspiciously installed in that conference room nobody uses)
-software should be kept patched and up to date, particularly web browsers. most competent IT Support is going to have an established update procedure using group policy.
-normal users will not have local administrator permissions. This would eliminate the threat entirely, as that would be required for any exploit to be installed via said web browser (again, excluding possible, specific privilege escalation).
Summary? Just another "hacker trick" that can be added to the pen-test book, with limited (if not entirely non-existent) applications in the wild.
