1) First off, as a fast apology and as mentioned lower in this thread, that FAQ answer about the NSA was rewritten two nights ago and failed to end up on the website; the updated answers have now been pushed (to say "Yes", actually, as the first sentence, instead of "No" with a qualification that essentially changes the answer to "well, yes").

That said, you are absolutely correct, and my colleague and long-time friend David Salamon (the person who has been the lead author of the whitepaper) wants that to be very clear. We are implementing bandwidth burning (and are even discussing some interesting extensions of this scheme involving both Turing-complete-w/-limited-execution-time programmable bandwidth burning as well as a form of global bandwidth burning), so whether you call that a "known weakness" for all of Orchid or not is slightly confusing ;P.

When we have actual software that someone could possibly use I am going to be pretty adamant that there are good disclosures in the UI with respect to the security tradeoffs, and for right now the whitepaper goes into extreme lengths to qualify what is or is not possible, in our current understanding, with and without bandwidth burning in place. (We are also looking into taking aspects of the algorithm and building it out with a proof assistant to have even greater assurances.)

2) One place where Orchid will hopefully shine (in the future tense, as this part is decidedly not yet implemented) is that we are working to allow multiple routes to/from the destination exit node using a scheme similar to MPTCP, which solves a lot of the bottleneck issues you normally find running through an overlay network.