I agree with you. I mean to say that after reading the author's ideas my takeaway was not that they were suggesting that I irresponsibly construct a single-point-of-failure system for a situation that demands a strong availability story. My takeaway was to mull over and challenge what the availability requirements are before building the ubiquitous cloud system that I'm familiar with. What tradeoffs are made and what risks are budgeted are not ubiquitous, therefore, our architecture should not be.
I, for one, appreciated the thought experiment and I took it for that: a theoretical alternative that would otherwise seem untenable being held up against a known pattern. I take it as theoretical because the author didn't actually build the system they're proposing for BusinessInsider, and without putting it into practice, I can only see it as that.
In practice, articulating and defining the cost of making choices is still the responsibility of the engineer and I don't believe the author was ignoring availability to suggest that we should too. In fact, I'm left with: "I find this proposal interesting, of course there are availability concerns, how might I solve those concerns from here?" The difference between that thought and the "straw-man" I pointed out is that the straw-man argument reads: "throw this all out because that system is only going to fail."
