Hey 
Ashley, thanks for giving a chance to share opinions.
I completely agree the current performance of the collision detection is enough for most of the games that comes to mind when using C2. However, I made the "mistake" on starting an rts game where I use collision detection for various events.
For everything below: I was monitoring the performance of collision detection via grouping the related events together and using debug layout.
I also know that the design is as important as the performance of the tools, if not more. And I am a newbie to C2, and relatively new to coding as all I know is some C# and XNA, in which I made a couple games.
In my current project, with just barebone elements like food and 1 type of neutral unit and some 1 enemy unit on a relatively large layout (22k x 22k) I can stress test up to 100 player units without any slowdowns (collision take 20 percent CPU, framerate stable —) and up to 300 units to playable levels. (collisions take 49 percent CPU, framrate stable —)
However when I introduce the opposing faction, 200 units each side trying to collision detect their enemies, as well as various resources on the board, it starts to show itself.(collisions take 90+percent cpu, framrate around 10) And due to the nature of my game, I would like to go up to 1000 units for each side. (units are not directly controllable, player creates units, creates groups from units, creates orders through map and attains groups to orders.)
As a sidenote, I am also using pathfinding behaviour which may add to low framerates somehow. But the CPU usage I detect from grouping the events and they don't include pathfinding events.
I tried several ways to remove collision detection from the design. Like I was using an invisible, LoS bubble sprite around units to find out if they have anything particular in their range, running collision checks with "collidables" family. I removed it for a simple, event driven distance check, which didn't improve performance much. Also currently my units are walking through eachother; with an improved collision detection it would be relatively easy (and admittedly lazy) way of doing something when they collide, like playing an animation at least. I also created a fog of war effect by using the flashlight method on shooter example, which was awesome!!! Units were leaving behind "destination out" circle "sight" sprites with fade when they the nearest "sight" sprite was at some distance. This meant all the player untis were checking distance for all the created "sight" sprites. Needless to say, even when I did this every .3 seconds, this reduced playability 
medium unit numbers. So I removed the fog of war.
I also tried to model the "spatial hashing collision detection method as described here via events and it actually reduced the performance. But it's possible that my events were just bad. I think "picking" itself is somehow costly.
And at some part of my game there are interiors, big caves or buildings where units can enter. At one point I thought I could use a side view here for interesting results, however I was scared of the platform behaviours need to collision check with platfrom objects for hundreds of units.
TLDR; I think not only for collision, but also for distance checks, and any behaviour that uses distance/collision, an aproach other than brute force could boost the power of C2 and open for more variation in gameplay made in games with it.
Whev. That was a lot. Thanks for everything already Ashley :)