So random academic question - Should it be literally possible for an OS to "brick" hardware even if the OS was intentionally designed to do just that? Now I know in this particular case Samsung wrote both the driver and the firmware, so it is easy to point blame here. But more broadly, should hardware be built/designed so it has a "fail safe" mode where it just won't allow its self to be damaged by OS/software instru…
Yes - hardware should be designed to always provide a way to recover from any failure mode that can result from software that's running on that hardware. Even bad firmware updates should be recoverable - what happens if you lose power mid-update?
I don't think you can expect both to be true nowadays. For example, chances are that your battery charging 'hardware' runs some software. That software, if replaced with faulty software, can destroy your batteries and with it, maybe even your motherboard (through fire, acid leaks, and the like)
This applies elsewhere, too. Historically, we had the 'killer poke' (http://www.6502.org/users/andre/petindex/poke/index.html; variants at http://en.wikipedia.org/wiki/Killer_poke).
Nowadays, it is rumored that buggy baseband firmware for mobile phones can fry the hardware.
I do not think it is feasible to prevent all of these in hardware. Because of that, you must accept "if you can update all software through software, you can brick your device through software".
So, to get to "provide a way to recover from any failure mode that can result from software", you will need to have some unmodifiable software on the device. You also will need that software to allow updating of some firmware and to be free of bugs. I think that is possible, but not economically feasible. Why would anyone spend even a week on bug-checking that earliest running code on a device that will be sold for only six months? That would be giving up the bestselling 4% of the sales cycle.