I could see it making sense. If you needed to iterate over thousands of elements, that's a fair amount of headroom /time spent on HTTP connection building for what is probably a simple operation. In particular, being able to POST a large collection in a batch seems useful.
There's lots of Java development that deals with money movement that is suspect. All languages and frameworks are just tools. It depends on how you use them. Compilers are no guarantee for correctness if how you're modeling types is improper.
I don't know anything about Whirlpool specifically. If you are impressed with their IoT group, that's great! I'll go pick on smart microwave manufacturers instead. ;)
My least favorite engineering problem is the "dusty router" concern.
At some point, you may want to version your apis in a breaking way. You'll spend weeks sketching out a migration plan for all active routers in the field, sell it internally , get a thumbs up, then try to prep customer support. Customer support might tell you that you still need to support some devices which were unplugged on a firmware released 6 months ago. Oops.
When building deployed firmware, you always need to include a reliable fallback that allows you to bump the firmware on that device, even when it can't talk to anything else wirelessly.
One of the things I am most skeptical about for the future of IoT is that it's just REALLY hard to get the basics of networking, meshing, security, and updates down without an experienced and dedicated engineering team.
Realistically, Whirlpool just isn't going to be able to field that team to make their laundry machine resilient to malware attacks or a bricking update.
I always thought the only way forward with IoT was if it a big tech player offered an SDK / IoT platform that allowed developers to focus on the widgety part of their widget without having to think about the complexities of running an internet connected device. This seems like a big jump towards that.