It is kind of like when you have a power loss while writing to a file system (like say FAT32 or EXT2) and when it comes back up you have to do a fsck or equivalent. If something gets messed up it may not come back in an consistent manner. Something similar happens at and SSD level. One of the most complex aspects of an SSD to implement and test.

Not sure, but I'm imagining it's to avoid someone throwing out a read-only drive filled with sensitive data (and unable to erase it through conventional means - that is, writing to the drive)

Of course, there are other solutions to this problem: sledgehammer, etc

A bricked device still has the data on it. It's fake security.

And you could allow secure erase while still prohibiting normal writes. The cells aren't actually gone or unusable after all, just unreliable. A secure erase would work fine on them.

"A bricked device still has the data on it. It's fake security"

No, because they do this http://vxlabs.com/2012/12/22/ssds-with-usable-built-in-hardw...

Erase the AES key -> data is gone

And, it would be extremely easy to implement, because you only have to assert erase on every page in the device, which can be done in parallel.