There are a couple of options as you are aware off [for having a faster microcontroller].
I would personally go for ARM Cortex 3, AKA SAM3U. Why? Because there is some basis to start.
https://github.com/kliment/4pi-firmware
and some boards: https://github.com/kliment/reup

Also, I think for the reprap community. And Reprap will never have as stable systems as commercial machines, since the last 5% of bugs nobody wants to fix without being forced to.
However, what reprap can be for the next couple of years, is to be the technological leader.
[Yes, I will come to the point]
For that, there need to be developer boards electronics that are easily hackable, easily repairable and modular. I think that this should be also applicable for space, with the focus on repeatability. Solderable without reflow. So this puts dramatic limitations on the chip. Or the way the controller is connected to everything else.
And this is why I believe in Arduino DUE, with its SAM3U chip. The connector system is not great, but allright, and the boards are reasonably replaceable. Also, you need no programmer, just USB. Also, the bootloader, however ever strange the second Atmel168 is, works. Please note that I am not talking about the ARDUINO SDK, which is not optimized sufficiently. Just the hardware, not the SDK.

ARM Cortex 4 would also be a nice choice, especially for Floating point support was his reason, 

There is an uncertainty in this hardware preference, and this should be taken into account.
The way to go in my mental map is the following:
a) the FW should be quickly portable to a different controller. Why? Because all commercial, monolithic boards will have their "own" controller maybe. And you want still to have a community working together to find bugs and create features. Split firmwares are not good enough very soon.
b) From a) follows, that their will be variants, and with variants, the proven way to go is to have externaly hosted libraries. E.g. for gcode interpretation. E.g. for Communication. E.g. user interaction. E.g. Trajectory Planning. E.g. Step Generation.  These libraries are as hardware-independent as possible.
This libraries all access the actual Microcontroller using a standardized interface. E.g. "set heater pin high" "set PWM to 50% on the fan pin" or: "do a step".

c) How to achieve this?
)Create a clean Hardware interface.
)Decide the library boundaries and its interconnections.
)Split marlin into Non-interwoven parts to fill the libraries.
)Milestone: First working librarized port.
) Then: use the new performance to add superior features.

Why is this better than smoothie firmware approach?
Nobody will contribute to libraries that are hosted within a different firmware. They are not neutral. And egos count in community-based software.

Also, you can create unit test for each library. And use a nomal computer with a validation suit by having a PC based hardware interface. (Easier debugging and validation)