I suppose it depends on your definition of success. For me it's more about medium and long term success, not growing quickly and selling out a couple years later.
Sure you can bang out a ball of mud that ticks all the right buzzwords of the time, but I've not seen this approach last more than a few years.
Having said that it can completely be a winning strategy to bang out an MVP quickly, knowing a major refactor will have to be done later. But I would consider that to be good engineering.
I suspect the definition of "good engineering" changes radically as company size grows.
For early stage startup, ability to iterate rapidly and get changes into production for consumers to see is everything.
With a large existing customer base and lots of hardware and software resources to manage, preventing bugs and outages, scaling, and reliability become more important.
As much as I want this to be true, I don't know that a requirement. I think a quick test is asking yourself "Is the engineering good at every successful tech company I've worked at?" and given a sufficiently long career I don't think the answer to this is "yes".