Majenko was very close but seems to have missed the explanatory comment from the source code:
// (I've deliberately left out pin mapping to the Hardware USARTs - seems senseless to me)
// Pins: 10, 11, 12, 13, 50, 51, 52, 53, 62, 63, 64, 65, 66, 67, 68, 69
#define digitalPinToPCICR(p) ( (((p) >= 10) && ((p) <= 13)) || \
(((p) >= 50) && ((p) <= 53)) || \
(((p) >= 62) && ((p) <= 69)) ? (&PCICR) : ((uint8_t *)0) )
Which seems like it may apply to the fact that the USART3 pins PJ1 (14) and PJ0 (15) are missing.
As for why providing mappings to the "Hardware USARTs seems senseless" a little playing with git blame will show that these lines were added to this file in commit f179794 in response to issue 490:
The SoftwareSerial library defines macros that map Arduino pin numbers to the pin changes interrupts on the pins. We should pull this up into the board-specific pin definition header file so that the SoftwareSerial library can work on any AVR for which those macros (and the pin-change interrupts) are defined.
Which is to say that dmellis didn't write those lines for generic interrupt use as part of pins_arduino.h, but rather moved code originally written as part of the software serial library to this file for more generic use.
It does kind of make sense that someone writing a software serial library could consider using it on hardware serial pins pointless. Though counterarguments could also be made - for one, the 16u2 core either uses or has experimented with software serial at some baud rates, and for another a software serial implementation could be a plausible way of overcoming swapped RX & TX wiring, or a way of implementing inverted signalling logic when using simplified level shifters or talking to something which expects to.