No. You have to spend as much energy as possible on end user features of which dev ops is the opposite.

Reliability and speed are features, and often the features that make users stay or go.

If your devops is inadequate, so that you have low visibility into your product's performance, can't degrade gracefully, and have trouble deploying things without significant downtime, investing in proper devops infrastructure and processes may directly help your bottom line.

As somebody who's actually paid to implement devops practices for many clients at scale, this is nuts. The only performance argument for a service-oriented architecture (and let's be really real, the overhead of HTTP means that microservices rarely have a performance argument at all) is when and only when you have specific requirements that cannot be solved by horizontally scaling a monolithic system. Until you have an actual, metrically verified demonstration of the failure of horizontally scaling your monolithic architecture, sticking with it will in almost every instance outperform your "microservice architecture". Reliability, too, is a joke argument; building a single application (whether or not you internally segment the code with an eye towards later service segmentation) means that you have N instances of every component, rather than N of some, M of others, and so on. And nothing related to deploying your very bloggable microservice should differ from a reasonably developed monolithic system in the first place.

The set of companies that have any sort of reliability or performance-oriented need a "microservice architecture" is three, maybe four orders of magnitude smaller than the set of companies building web applications. They--and you--have been sold on a trend that is actively antithetical to the goals of delivering a product.

Build your application. Use an auto-scaling group and an ELB. You have more important things to do until you reach the scale where you can pay someone (hi) to do them.

I did not try to defend microservices. I tried to note that devops is not an opposite to customer-facing value.

I think most of your points are valid (wherever my experience is enough to judge).

That stuff is table stakes and relatively easy to deliver in 2016. Compared to achieving product/market fit and getting people to pay for your service, comparatively simple.

Comparatively simple, but without getting at least the basics right you'll be moving comparatively slowly as you end up with time-suck after time-suck to compensate for lacking processes.

If you don't have proper devops processes in place, you'll be spending a progressively larger proportion of your time handling manually what should be automated, and firefighting problems that shouldn't even occur, as your system grows more complex.

A pre-requisite to "spend as much energy as possible on end user features" is to have some sort of foundation to build on that can grow with your platform, or you might as well build on quicksand.