Very late to the party, but here is my take, since I had a different project with the same microcontroller/PI hardware. . . It may help someone in the future.
Iy my project, the Pi is used as the master controller, and for displaying results, accepting user inputs (e.g. parameter changes, etc.)
The STM is a satellite I/O controller, driving outputs in response to either master controller commands or in response to input events.
The STM also monitors inputs at speed, buffers results, and when polled reports the results back to the master controller.
After consideration and some experiments, I chose one of the STM's SPI channels as the intercommunication for several reasons.
The only inter-communication is between one STM and one Pi. No multidrop, although the second SPI channel on the Pi is used to read/write to a SPI FRAM to persist data. So the multi-slave capability of IIC, while sometimes very useful, was not needed.
The speed is much higher for SPI.
Using SPI left the STM's IIC channel free in case I needed to add a bunch of IO in future iterations, or for similar designed with different IO needs. In fact, I did just that on another device that only needed a lot of outputs and not a terribly fast speed.
I had total control of the comm protocol, so I could optimize things for SPI. IIC devices are often more chatty. I did implement C0BS for rudimentary error checking, but that was not expensive.
The SPI transactions are bidirectional and interleaved. I only had summary data coming back to the master controller, so I could get it at the same time the master controller sent a command or polled the STM.
All in all, it worked fine. My only concern is that the WiringPi library is no longer being supported by Gordon, and he hasn't released the source code for his last revision. Some day I may need to dig in an write a kernel driver to replace that C library.
Hope everything worked out for you.