IGPs use sideport memory most of the time, which is basically a block of memory siphoned of your system's main RAM. Depending on how this is implemented, it can be ridiculously slow to transfer data from RAM to sideport memory although physically it is on the same PCB. This is due to the fact that the abstraction mechanisms in place have to "pretend" there is a physical discrete GPU although there really is none, and the data probably has to travel around half the system to reach its destination. There are so many other things that could contribute to it being slow (how the IGP interrupts are handled, what kind of bus is used to connect IGP and memory controller, what the driver does to provide full OpenGL functionality, sometimes processing is split between IGP and CPU, etc.)
You shouldn't really wonder why something that doesn't promise to be fast is slow. I would worry more if something that promised to be fast really is slow and be surprised if something you would expect to be slow is fast. That being said, I don't know how PictureBox is implemented, but one possibility is that there are optimizations involved in the background that you don't notice. Being from Microsoft, you might also expect it to be implemented in terms of DirectX (with its HAL and HEL it probably provides more room for optimizing IGPs than OpenGL, which is what SFML uses) or more likely GDI which is probably also optimized for IGPs since it is the staple rendering mechanism of the Windows UI.
