Have you even tried the Duet?
@Jeff_DeMaagd Preston is trying to solve problems that don’t exist, but it’s interesting to see what he comes up with. Might as well roll with it 
I’m good with that. I would want to make sure that the reference isn’t just against something like Marlin but also firmwares and boards that offer capabilities leaps better than Marlin.
@Ryan_Carlyle Heh. You might be right.
On the other hand, I have a history of making WAGs that turn out to be right. Not every time, but more often than I would have guessed.
My guess is that 3D printers are about to get a lot smarter. That means much faster movement and reliable extrusion. That means more predictive heating and adjusted movement. That means a lot more computation.
That means more software. That means we need to ditch the niche hardware platforms. That means 8-bit controllers (even upgraded) are a non-starter.
That means the 3D printer hardware market is about to re-discover the lesson learned by the PC market in the 1980s - software is the center, not hardware.
This is all an extrapolation. On the other hand, my wild-assed-guesses have turned out right, rather a lot.
@Preston_Bannister a lot of this stuff is just starting to move into the cloud now. And RPis are getting really common for handling the non-realtime stuff like slicing and GUI management. So I think you’re right on the main trend. My main point of disagreement is where you want to get rid of the custom hardware… you inevitably need power MOSFETs for motors and heaters, so it’s unavoidable that there’s either a custom hat/cape/shield or a companion board hooked up to the RPi. That’s physics, not design decisions. Then once you’re already designing custom hardware, you might as well put whatever coprocessor on there is convenient to overcome the shortcomings of the RPi CPU.
@Ryan_Carlyle , what I think @Preston_Bannister is getting at is: the perceived “shortcomings of the RPi cpu” are in fact shortcomings in the RPi software.
Everyone has taken the path of least resistance. Which is to throw a bit more hardware at the problem.
The comments in this thread have named 2 dozen ways to take that low resistance path, and exactly no ways to take the harder way. Programmers are lazy (like mathematicians). But hardware types are overly overly pragmatic.
We need some people to climb mountains and do hard things. It’s not unusual for them to hear a chorus of “don’t do it because it is hard”.
@Josh_Rhodes a piece I think is missing from this discussion is that processor designers do entirely different chip hardware architectures for processors intended for embedded systems like 3d printers, versus processors designed for computers. An ARM M4F in a Duet is designed for hardware control, while an ARM A53 in an RPi3 is designed to run an operating system and software. They have different hardware processing modules and IO hookups. (Count GPIO pins and it’s really obvious.) So what we’re talking about is literally using the wrong kind of hardware for the application, and trying to figure out how to make that work.
If you have a hammer, everything looks like nails. There is definitely the right tools for the job, and the wrong tools. You can spend an enormous amount of time trying to get the wrong tool to work, or “take the easy route” as you put it.