All of the listed reasons relate to the experience of software development, not the user experience. Of course it's harder to maintain native apps plus a web fr

All of the listed reasons relate to the experience of software development, not the user experience. Of course it's harder to maintain native apps plus a web front end to a service. Users don't know or care how many developers were involved or how much money it cost or how much of a pain it was to keep everything consistent across multiple code bases. They just want the least terrible experience possible. I don't think there was ever a myth that needed to be debunked that everything should be native, both approaches have their pros and cons. All that really matters is how aware you are of what those pros and cons are, and how you weight the ones that you are aware of given your context. Collectively that determines if you need a native app or not. Most likely neither approach will be ideal (i.e., pros == 1.0 and cons == 0.0), so the real question is what heuristics do you use when choosing your poison for your project and for your team. Towards the end it seems like that's the point that was being made (i.e., "nothing's perfect but here's why this was the best approach for us in this particular case"). That's the opposite of what was promised up front though.