Heh, I think I've read that post too. Ultimately, I determined that you either need: Physical access to the device, or software update access to the device (either through firmware updates, or hardware reprogramming). Thus, if you do not have update-able firmware, then it is a non-issue. And if you do have firmware update-able code, then it comes down to how well you protect that update process. The vulnerability is mainly aimed at Cypress' supervisory code that controls the chips/core directly. It can be modified by the developer's application code, but ultimately, unless they have the ability to write code to the chip, they will not be able to access the vulnerability.
Also depends on where you get your chips from, and the path they travel to your hands.
Anyways, I guess this issue is a problem only for really specific applications (or high volume), such as military / aerospace and the like, and I bet you can verify your chips (although, of course, is added work which may not justify given the availability of other options on the market). I know there's a thread about this in the forum (where the discoverer of the issue also comments).
Good point about the travel path; If you are shipping or receiving it from someone, then it could be suspect :/ Although, this is part of the checksum verification I suppose (not foolproof by any means, but makes it less easy to fool)
Here's the forum thread here (that you mentioned): Double the flash in low-end PSoC4 for free
Theoretically, if you used the exploit yourself to fully use the entire flash space (supervisory as well) to write your application code, then any attempts to apply rootkits or similar things would cause corruption of the image as a whole. >:)
But still, security checking of the code would be required for extremely secure applications
On the other hand, if I was a wealthy organization with a security requirement, I would probably develop my own security hardware and software measures to instigate the prevention of rootkit installments.