After trying several ways to work around this, I finally gave up, got rid of the QPainterPath and implemented a QGraphicsItem to draw the line segments manually in the paint() method. Turning on the DeviceCoordinateCache flag enabled good performance for zooming and other operations.
Had exactly the same problem (way, way back), solved it exactly the same way.
Since the solution was to get rid of QPainterPath, which is NOT part of the QGraphics Framework, and relay purely on the Grpahics FW side - which proves that Graphics FW actaully is much more perfomant, then using the regular painter.
I admit the QPainterPath bit escaped me when I read the OP post . (but I am reading the posts during work, so quite fast).

The 40000 chips demo is not a good example for this issue, because it does not use QPainterPath, but draws each chip at the appropriate LOD on each paint() call. At the most coarse LOD, it is simply drawing 6 lines for each chip, so certainly it is blindingly fast. And at the finest LOD, there is just a bit of text and only a chip or two is visible. Each chip has only about 100 bytes of internal storage in addition to that used by QGraphicsItem, so even 40K of them is only 4 MB of memory plus the base class overhead - tiny.
Well, when you go about dealing with millions of items, I would expect to have performance issues no matter what system I am working with, and would go for very simple items.
Have millions of complex items on one side, and expecting miracles on the other (have them shown in a millisecond) at the moment at least, is not really sensible.


One more tip to OP:
You can use OpenGL (hardware acceleration) if you set your viewport to a QGLWidget.