I2C puedes relentizarlo, ya que todo se hace al ritmo que marque la señal SCL, que es un clock un poco especial, y que lo genera el master. Peeero no es suficiente. I2C, es muy sensible a ruido e interferencias, por el tipo de señales que utiliza. De hecho, creo que originalmente estaba previsto para distancias menores que 1m, para comunicar distintos chips dentro de una misma placa, o como mucho, dentro de un mismo aparato (I2C = IIC = Inter Integrated Circuit -creo-).
Existen sistemas que utilizan el misma sistema que I2C, que utilizan señales menos sensibles, pero no hay un estándar, así que no creo que encuentres sensores para un sistema así, sino que tendrías que añadir conversores en cada sensor. El propio sistema CAN podría ser una opción, pero tampoco tengo conocimiento de que haya sensores que directamente usen CAN.
Ahora bien, si lo vas a hacer con un PIC programado por tí, seguro que te interesará mirar los sensores DS18S20 y DS18B20 de Dallas. Utilizan el sistema 1-wire de Dallas, es decir, 1 sólo cable para la comunicación, más los dos de alimentación (un cable menos que con I2C), y la longitud máxima de los cables esbastante grande (no recuerdo ahora, pero creo que 100m o algo así). Incluso permiten directamente alimentarse del cable de señal (es decir, sólo dos hilos, masa y señal + alimentación), pero esto limita sus prestaciones.
El sistema es multi-slave, como el I2C, y cada sensor tiene un único código de identificación programado en fábrica, con lo que los sensores sólo usan 3 patillas, y puedes poner casi tantos como quieras (los I2C que conozco llevan 3 patillas para codificar su identificación, así que como máximo sólo puedes tener 8 por bus). La comunicación es relativamente lenta, pero eso te da igual, y los sensores no son caros, ni difíciles de encontrar, y además son sampleables.
Eso sí, no encontrarás rutinas ya escritas para este tipo de comunicación, pero yo los he usado y el cronograma es de lo más simple de implementar.