Why the need for multiple I²C ports?

Sensor hub arrangement

In this scenario, there are two I²C buses. Let's call them local bus and main bus. The purpose of the local bus is to connect a bunch of sensors to a microcontroller (μC). The purpose of the μC is to poll the sensors, aggregate information from them, and detect certain events. A μC in such role is called sensor hub. The sensor hub is not responsible for higher order functions; there is a powerful main processor for that. The main bus connects the sensor hub to the main processor. So, the sensor hub μC is a master on the local I²C bus and a slave on the I²C main bus.

SPI and I²C

The PIC linked in the original post doesn't share the pins between SPI and I²C. However, there are other PICs that use the same pins for hardware SPI and I²C, because both are implemented with the same MSSP peripheral. If a PIC has two separate MSSP peripherals, then one can be used for hardware SPI, while the other one is used for hardware I²C.

A very common reason to need more than one bus is having devices that run at different speeds. Originally, I²C ran at at a maximum 100 kHz. Later, the speed was increased to a maximum of 400 kHz, and still later, to 1 MHz and above.

The gotcha is, since the address of each device is embedded in the I²C protocol, then if you have devices with different speed ratings on the same bus, say 100 kHz and 400 kHz, you always have to run the bus at the lowest speed common to all devices on the same bus (100 kHz in this case).

If you ran the bus at the higher speed (400 kHz), obviously the lower-speed device would not work properly, and it might even interpret the address of the high-speed device as its own, causing the 400 kHz device to fail as well. But even if you initially ran the bus at 100 kHz, and then tried to speed up the bus to 400 kHz after addressing a higher-speed chip, it would be possible (although probably unlikely) for the lower-speed chip to interpret one of the high-speed data packets incorrectly as its address, and thus mess up the communication on the bus. In either case, at the end of the interchange with the 400 kHz device, the 100 kHz device would probably be in an unknown state.

So it is most efficient, if you have devices running at different speeds and you have multiple I²C ports and you have the spare pins to allow for such luxury, to have one I²C say for 100 kHz devices, another for 400 kHz devices, and another for 1 MHz devices, as your needs may dictate.

This is not an issue with SPI because each device is enabled (addressed) in hardware by a separate chip select line. So the clock speed can be matched to the speed of the selected chip (10 MHz, 20 MHz, whatever) without having any effect on other chips on the same bus, since they are not enabled.

Also it could let you support two devices with the same address. Yes most devices let you select maybe the bottom two bits of their address with straps. Recently I had to support 4 devices who each only allowed you to set the LSB of their address with a resistor. Having two ports means no extra cost for me.

Maybe I want one to be the master for a bunch of devices and present the other as the slave port, so my master doesn't have to wait to grab the bus to give me a command while I poll a temperature sensor for the 10,000th time.

There seem to be a bunch of other good responses in this thread, just adding my 2 cents.