The reason for secrecy in the initial development is because there's lots of money involved, and getting a feature "first" makes a publicity difference.

I agree that in the long run it's not beneficial.

The problems mentioned in that reddit post seems serious, btw., but they're easily mitigated by applying relatively simple changes. E.g.  split up transactions and normalize amounts combined with more volume. The example is somewhat contrived because it depends on having low enough volume passing through the mixing nodes to be able to deduce the amounts. This will still leave odd transaction amounts vulnerable (e.g. someone transferring 9.15153 will be easier to trace than someone transferring 10, because presumably the likelihood of other transactions of value 10 also passing through is going to be much higher). Implementation is also going to matter a lot since e.g. timing attacks is an issue with that kind of model - a proper version will apply random delays, and will intentionally process transactions "out of order", and make sure to interleave partial transfers from multiple transactions.

The central node issue is a bit ugly but can also be mitigated somewhat by splitting up transfers and mixing through multiple (hopefully independent) nodes (this is basically the Tor model, and is still vulnerable if an adversary controls enough of the nodes).

None of this is unfixable, and I don't think it's a major issue with taking first stabs on these implementations in private.