Good examples, and all that is true.
That said, I don’t expect anything to be perfect. When it comes to low cost residential systems, Including home automation systems, I use a specific measurement: MFOP (maintenance free operating period).
That’s an engineering term which means how long can the typical end user Expect the system to operate reliably without requiring any maintenance.
For example, the typical MFOP for a dishwasher is two years. For the first year, there typically are no problems and no maintenance is required. Somewhere around two years, you might need to clean a filter or even change a hose or a water seal. It’s just The way they are engineered. you could make one that was maintenance free for 10 years, but it would have to cost a lot more.
MY PERSONAL REQUIREMENT
My target MFOP for home automation systems is a minimum six months, and I prefer a year. A year in which I don’t have to do anything with the system, it’s “set and forget.“ It works the way I set it up to work. 
Over the last five years I haven’t had any problems achieving that target with multiple home automation systems, including Amazon echo, Philips hue, Apple’s HomeKit, ring security, Logitech Harmony, Lutron Caseta, and Wyze with the included sensor system. But with smartthings I have been lucky to go two weeks, And I have never gone as much as two months. 
It’s not the devices themselves: many continue to operate during the same timeframe on another platform. But it’s always something. The cloud, the app, a stock DTH, an integration, the way the rules work… Something fails. Here’s a good recent example from someone else:
My own system is not complex. I have never had more than two dozen devices and I use as little custom code as possible. I don’t use webcore. Smartthings as delivered is just fragile. Versatile, but fragile. And they make a lot of undocumented changes which can be neither deferred nor denied.
THE FIX MAY BE SIMPLE, BUT IF A FIX IS REQUIRED, THAT RESETS MFOP
Sometimes it’s just a matter of opening the app, going to a particular screen, and saving something again. Sometimes it requires logging out and logging in. Sometimes it means rebooting a device. Sometimes it means understanding how one of those undocumented changes works.
My problem is that as someone who is quadriparetic I have to pay another person to do any of these “minor“ fixes. That’s why the MFOP matters so much to me, and why I am willing to pay more for a system with a longer one.
Right now multiple people are reporting that automations that they had set up for months or even more than a year to manage changing the STHM mode have started going into a loop. They didn’t change anything. There were no announced changes. But their security system is disarming and re-arming itself, or the other way around. There’s a workaround, which involves changing to a different DTH, but obviously that blows the MFOP.
And smartthings has a lot of these kinds of issues. They don’t affect every customer every time, But there are enough of them that very few people can say that their system operated reliably and required no hands-on maintenance for 12 months. The fixes may have been minor, but they were needed.
NO SYSTEM IS PERFECT, BUT THEY AREN’T ALL THE SAME, EITHER
So while it’s true that no system is perfect, and that if a use case is critical you should expect to plan for some kind of redundancy, it’s also true that different systems deliver different levels of reliability as measured by MFOP.
And I think it’s measurably also true that the smartthings MFOP is lower than many competing systems. That doesn’t mean it doesn’t Have some Features that would compare favorably with those same systems, it does. So each person needs to judge for themselves which system is the best match to their own needs and priorities. 