well, is it better to have a hacked MVP released in production, or spend forever making it and never actually releasing it and then missing the window?
That said, "flawless accounting" would be very high up on my feature list. I think the failure here isn't launching without perfection; it's operating at scale without perfection.
I think minimum feature scope doesn't necessitate poor-quality software, just solutions that don't do everything for everybody. It's much better to ship a small feature set with very high quality, IMO, than a big feature set with low quality.
In the Lean Startup sense, the M is about minimum effort, and the V is about viability with customers. You're basically playing Battleship trying to discover where those two Venn circles overlap.
Different aspects of quality map to both those circles. There's build quality, which relates to the sustainability of the code base. There, you have to consider both short- and long-term quality. [1]
There's also quality as users perceive it. That varies widely by domain by market, and by how far you are along the adopter curve.
My general answer is the same as yours: minimal features with highly sustainable code. But for experiments, I think you can get away with terrible code as long as you a) throw it away quickly, and b) you are on it so even if you have a bad MTBF, your MTTR is really good.
I also think that you can tactically discard certain kinds of user-side quality. E.g., if I'm making a product for early-adopter financial traders, I'm not going to worry about quality of visual design, and I might inflict hard-to-learn interfaces on them. But I'd be rigorous about accounting and about UI issues that might lead to mistaken trades.
[1] I wrote some about that here: http://agilefocus.com/2009/06/22/the-3-kinds-of-code/
Or do you mean this as a metaphor for MtGox? In that case, I would say that I would rather miss the window than be the famous asshole who -- oopsie! -- lost $500 million of other people's money.
One of the biggest risks is, "nobody gives a fuck", which is why MVPs are so valuable. It lets you test market hypotheses.
But if you're building something handling real money, then a pretty obvious risk is, "The system will lose money beyond our capacity to absorb losses." Their failure to address that risk here is at best negligence.
But given the size of the loss, I don't think we should rule out fraud. The interesting question is, "When did they know they had a problem?" Sometimes shitty accounting systems are just naiveté. But when they persist over a long period of time in a way that just happens to cover up loss, embezzlement, or theft, then it's worth asking: did they keep the shitty accounting because better accounting would have forced them to admit something they were hoping to cover up?