I haven't looked too much into the general case. You could consider a tuple (R1, R2, ..., Rn) and compute the probability distributions one at a time for R1, R2, etc. I don't want to get sucked into the exact details of how to do that, but I think it would involve some head-wrecking combinatorics in a loop. Then you could do the same for G and B.
Like you implied, this would be slow if you did it 1000s of times. That's why I pre-computed the R probability distribution in my code, which unfortunately would not be applicable to the general case because there would be too many possible distributions (exponential) to pre-compute. To generate 1 set of RGBs, however, I think it would be fine.
Alternatively, you could try a non-combinatorics interpretation. The folks on Reddit (thread linked in the article) suggested a geometric interpretation of the problem, which might work better.
There's also the approach I suggested at the end of my article: compute the number of possible tuples that average to A (one-off combinatorics), generate an index k between 1 and this number, then pass k to a magic function f that spits out the kth tuple. I'm just not sure what f would look like, hehe. It could be a recursive function. Not sure how to write f without having to do the same probability / combinatorics as before. Or looping through all possible tuples (yikes).