I2C: Is DMA required?
It's quite possible that the reason for using DMA may be found in the STM32 errata (the link is for the &laquo;high density&raquo; stm32f101/103 subfamily), a document as fascinating as the reference manual itself. Basically, the I2C peripheral is broken in many interesting ways. One of errata items (2.11.1) states that certain hardware events need to be serviced immediately, or some kind of hardware race condition may occur:


  When the EV7, EV7_1, EV6_1, EV6_3, EV2, EV8, and EV3 events are not
  managed before the current byte is being transferred, problems may be
  encountered such as receiving an extra byte, reading the same data
  twice or missing data.


Basically, the correct operation is not guaranteed in all cases unless I2C is serviced by highest priority interrupts (Workaround 2) or DMA (Workaround 1). Now if I'm reading it correctly, a simple polled transfer with all interrupts disabled would work too, but that's against the whole design philosophy of Cortex-M (concurrency goes out the window). If a preemptive RTOS is used, it's even worse. 

That said, multiple people have got I2C working in both polling and interrupt modes without strictly following errata recommendations and without apparent problems. This however cannot be taken as indication that a problem will never occur, of course. If you're going to implement your own I2C driver, I'd recommend that you handle not only all possible error conditions as signaled by the peripheral, but timeouts as well. If an error or a timeout happens, make sure to send a STOP (to reset slaves) and reset the controller itself as documented in the manual. Receiving bad data from slaves is also a possibility that you should think about. You can find many discussions of this problem in ST forums and elsewhere.