1. The largest prime number closest to the power of two (2^255 – 19) was defined for modular arithmetics speed up. 
2. The order of group 1 (another large number) was obtained when the group order for this curve was calculated.
3. Basepoint for EdDSA corresponds to the basepoint of Curve25519. These curves are birationally equivalent. Curve25519  uses the base point x = 9
4. Coefficient 486662 for Curve25519 (and, respectively, coefficient 121665 for EdDSA) was chosen the same way.

More detailed explanation of each constant choice can be found there: http://cr.yp.to/ecdh/curve25519-20060209.pdf

The proposal by Adam Back does reduce the size of ring signature. In case of large ringsig it maybe roughly two times smaller. However, from asymptotic point of view there is no difference from CryptoNote implementation: it is still a linear dependence O(n).

First of all, I must admit that their idea is worth looking into. However, I'm not sure whether the problem it is trying to solve is relevant when everyone uses the software that uses the protocol properly. BCN automatically splits outputs into standard sums (e.g. 136.7 -> 100+30+6+0.7), so there are plenty of outputs for any ring signature. And if someone forms a transaction manually thereby creating a non-standard output (without splitting) the outcome of such an action is his sole responsibility.
 
To praise inventors’ acumen, the scheme they offer does work. It allows to use a single output (amount=V) in different ring signatures with any amount less than V. Namely for every n-value there are floor(V/n) outs of amount "n" and one out of amount "V%n". Receiver is able to recover all private keys for some specific "n", while others can use every possible out public key (for any n-value) in their ring signatures. So that any output can be used in any ring signatures with lesser amount. I won't duplicate the math; it can be found in the paper.
 
Unfortunately, there are a few drawbacks to the scheme offered.
 
1) Outputs. BCN has 10-13 outputs per transaction, including the change outs. That's why it is a challenging task to determine the exact amount of an actual transfer and the change. By reducing the number of outputs to 1-3 we lose out on anonymity, just as it is implemented in BTC.
 
2) "Real"/"ghost" outputs bias. A recipient is tied to a specific n-value (chosen by the sender). When he will have spent all "real" outputs for key P, there will be floor (V/n) outs of amount "n" and one out of amount "V%n". Other users are likely to utilize different n-values and choose them randomly. When analyzing the blockchain i.e. looking for every possible spending of the P-output, a researcher will see a bias in specific n-values. Moreover, it is very likely that a researcher will find that all these "n"-transactions have sum of V – which in turn reveals the outs as "real".
 
3) Shared n-value. Let's leave aside a method of transferring this value to a receiver (the paper does not describe it, implying that the both parties know it). Even if the distribution of n-values is nearly uniform, the sender has an opportunity to trace the subsequent transactions by monitoring all possible spending with "n" value he knows. The additional rule that condradicts the anonymity: i-values should be different when the "real" outputs are spent.
 
The bottom line is: although the scheme offers smaller transaction size and larger amount of possible outputs it cripples the anonymity feature. All things considered it is not a good trade-off.