Just arrived here via an unrelated search… some corrections here:
One reason is the version of aerender you are using is probably not implementing properly -MP flag (aerender works like MP off for me in render queue in CS5.0, bug filed).
If you send N aerender each working on a segment (e.g. frame 1-100 for first, 101-200 for second…), you should see about the same render timing as MultiProcessing in render queue. On 12 CPU to give you an example sending 12 aerenders at once is 3-4 times faster then one. That is each frame renders 3-4 slower but you have 12 times less frames per render instances.
Since compositing by definition implies a lot of images in, the main issue with multi-processing is you become quickly IO bounded – that is most of the time is spent waiting for images (as you now have 24 processes instead of 1 reading from the same disk, the bottleneck is not necessarily processing power). You sort of need to scale the hard disk bandwidth (e.g. TBs raid) to match all that CPU. Also it quickly gets worse if all these renders at once move the data over the network.
That said, I would say if a machine is also used interactively then always go for less but faster CPU. For a render-only monster, some attention required at the IO level for this to scale properly. The ideal scenario for a multi-user setup could be (and AE might not be totally there yet) to have the app cache frames requested to an SSD when in the interactive app and maintain the media assets on a big/fast RAID attached to the render monster.
Pierre
https://www.revisionfx.com