My guess on this is based on the document I found from TI, which explains the bits used in a CAN message.
There you can see, that the extended 18 bit identifier is followed by the RTR bit and two bits called r1 and r0 (reserve bits) which currently have no meaning and could probably be used in a further extension of the CAN protocol.
So the PIC peripheral has to generate those bits in the frame somehow. I'd guess that if you set them to 1, the frame will contain a reserve bit of value 1 - currently not used and depending on the other side this will have no impact.
Choosing not to hardwire these bits to 0 is quite intelligent as the peripheral will support a future extension to the protocol without a change in hardware.
The documentation by Microchip could be clearer in that point.
Another common reason for reserved bits are internal test modes for the peripheral (for chip level testing), but usually those are hidden from the users in some way.
As a note: Don't use these bits for your own extension to the CAN protocol just because they are not used now and are useful for your application (everyone could use 2 bits more in a data frame right?), sooner or later it will break something, probably in the most horrible way.
A better source is the actual specification like this document from Bosch, where it states:
The CONTROL FIELD consists of six bits. It includes the DATA LENGTH CODE and
two bits reserved for future expansion. The reserved bits have to be sent ’dominant’.
Receivers accept ’dominant’ and ’recessive’ bits in all combinations.
The control field comes right after the RTR bit.