Bricking the device remotely may be a criminal offence if it's not specifically permitted in the EULA. And if it is permitted in the EULA, that term may not be enforcable. And if it is enforcable, then all consumer reporting/review organisations should point advise you never to buy the product.
Certainly if one of my devices got remote-bricked I'd be taking legal action.
It's very poor form to sunset a product without offering users (your early adopters none the less) a easy migration path to another product. Had there actually been data standards for setup and captured data, I'd expect the ability to export my setup and data so that I can use it to configure an alternative product.
But later on, as always-on-devices are the norm...I do think it'll be more acceptable -- with the appropriate regulations and consumer protections -- to kill a device at the end of the cycle instead of designing it to operate as a zombie, in the same way that users accept that MMOs and other multiplayer-heavy games are heavily dependent on company servers...though in that case, it's easier to design a game to allow non-official servers so that the community can carry on after the official shut-off...but that's where the analogy of video game == important home device ends, of course.
This is the irresponsible part.
When a product is initially released, users come to expect that support. If a company needs to shut down a product line and continued support...sure, ideally, users will pay attention and slowly migrate to new hardware when they can, just like people are still getting by with cars that have deadly airbags because they haven't had the time to leave their car at the shop...but as devices continue to have a feature set more dependent on the cloud and instant-push-updates...is there potential harm in letting a life-critical device function in zombie mode in such a way that it's good enough for months or even a year after the shutdown, but may be deadly sometimes afterward? The additional problem that connected devices add to the mix is that consumers have a hard time distinguishing between what features require the cloud and which features can work independently.
Obviously, there should never be the situation in which a critical device just dies as soon as the company shuts down its servers. Life-critical time-sensitive things, such as a heart pump, should thus be designed to operate independently, with connectedness being an optional feature.
But for other things, such as a smoke alarm...if a company designed it in such a way that connectedness is essential to its functionality, and that its usefulness in zombie mode can't be predicted a year down the road...can't it be argued that it's more responsible for the company to give the user a hard cutoff, rather than allowing the user the false comfort of zombie mode?