These are all not quite multi-TCP and there was no real mention of fairness of PCC against a single TCP stream, even of the CUBIC form, not to mention just plain old NewReno.
I can't tell if it's really unfair as I didn't test it myself, but they hint that there is a wide gap between PCC and NewReno or even CUBIC. The algorithm as I understand it also seems to imply that PCC will dominate a NewReno stream with ease, especially when PCC is an established connection and the NewReno is only starting up as the PCC will feel a small bump of losses, probably not do much about it (i.e. not reduce rate by much) and the NewReno generated packet losses will fly under the radar of PCC. At least that's the feeling I get from reading the paper, again, no idea about actual behavior but I'm no longer paid to look at packet traces of congestion control algorithms. (Shame, it was fun while it lasted :-)
When it comes to bufferbloat, a single TCP flow can dominate all others and be highly unfair because TCP's congestion algorithms are so slow to react (they often only react to packet loss and not latency).
LEDBAT and delay-based congestion algorithms were designed to handle bufferbloat well, and PCC is essentially a superset of these, taking into account loss rate and throughput in addition to just delay.