I am 80% certain that this cultural stance is going to be why XMR is beaten by another effort that understands better how to spur innovation by not suppressing or expecting a Cathedral style of progression.
The cultural stance is not significantly distinguished from the range of cultures I've seen on other open source projects on which and with which I've worked, which is quite a few.
Your characterization of it as a cathedral is straw man.
Perhaps it is a cathedral compared to your internal mental model of what constitutes bazzaar-style development, but by the standards of reality it is not.
Reality is the bazaar has been ongoing on this forum for years now. And you can't stop it. Don't you see all the experimentation in altcoins and all the wide-open discussion of ideas?
Your microcosm is your reality, but it is not the only reality.
For example, you were overruled on higher level of perpetual debasement. Some other coin will do what XMR doesn't.
My point is also that the Inverse Commons is not just intra-project, rather it is also inter-projects (as in the distinction between intrastate and interstate).
XMR is competing for developer resources, not developers competing to code for XMR as is the case for Linus.
You are equating the ability for a user to wait for say 6 confirmations to have a mathematically quantifiable probability of assurance, with the risk of a coin vulnerability allowing spends of any age to be double-spent (reverting a spend is double-spending).
No, I'm saying that any recipient of any coin is vulnerable to a chain fork, which is a judgement of the recipient that they have waited "long enough" for such a chain fork to become unlikely. I said nothing about 6 confirms. In practice recipients make their own judgement about number of confirms. In Bitcoin many use less, and in altcoins many require far more. In all cases there is likely some sort implicit or explicit fraud scoring, but that is really none of my business and is up to the recipients to sort out. Ring signatures do nothing to change this except what they are intended to do (inhibit tracing, and thus indirectly blacklisting), and nothing here is remotely specific to Monero.
Afaics, you entirely missed my point.
You had a category error. You compare quantifiable (known a priori) probability with attacks that have no quantifiable (no known a priori) probability of assurance. You compare from the perspective of the user a knowable and user-selected risk with an unknowable risk and no possible user choice (other than to divest).