The typical customer support process is bad for the complicated edge cases, which sometimes end up in threads like these. But it's good for business. You don't want your engineers attending to one person's problem. That's called consulting. You want them building product. Building perfect software is bad from a business point of view. In WPEngine's case, the takeaway from all this is to add a line to the customer requirements list on their website (useful for filtering out the undesirable bottom 5% of customers) that says they will not accept any of the few potential customers that use the native WP commenting system because it's poorly built.
I'm not sure if it's true, but based on the poster's description of WPEngine's customer support experience, it sounds like their customer service is the typical poorly structured (from the customer's point of view) customer service experience I've encountered and/or witnessed many times from companies both large and small.
Some startups don't provide phone support. It's nice to see WPEngine does. Sometimes you just have to talk with someone to beat it into their heads that you have a complicated problem. They can't email email you back a link to some topic-related doc page and move on. They're on the phone with you and they have to make meaningful progress before hanging up.
In the case of email support, 95% of the tickets are answered with a link to a doc page and that's the end of the case. The metrics are excellent and every pats themselves on the back. 95%! And the volume was soooo high! Acknowledging positives is necessary, but measuring failure requires different metrics and 95% success does not necessarily imply 5% failure because each one uses different metrics. You think the the metrics on their dashboard will take into account this thread, for example?
The system breaks down when the customer has a more serious problem. It takes support a few emails back and forth to realize it. The case is handled by random folks based on availability, further degrading the experience. The person who'll pick up your latest reply to the thread isn't going to thoroughly read the whole thread, and by this point you've interacted with five support staff already. Finally, they realize it's outside their control and pass it off to Engineering, where it languishes for a month. Creating a system where the engineer is not allowed to reply directly to the customer but instead has to reply to support who then replies to the customer only removes the stress off the engineer, so they can care less and not solve the problem. Meanwhile, the support staff learn to drop lines like "Sorry for the delay. We appreciate your patience. The engineers are still looking into it." without any second thoughts.