Using a floating movement comp means applying an input vector every frame (called TraverseDir there) multiplied by a Speed coefficient. So, technically, nothing can slow you down / speed you up since you override it anyway. Or perhaps this needs adjusting:
Velocity values for the above. Needs testing for more than a couple of mins, surely, though. 
The result seem OK at a glance but who knows how far you need to take it and what you’ll run into:
From my experience, the biggest gripe with this method is handling inter object collisions as movement comps don’t like other movement comps. It needs a separate calculation on impact.
When it comes to using physics for this, have a look at this thread: Trying to make a ball that speeds up after each bounce AND doesn't get stuck between parallel walls. - #5 by Everynone
CCD (optional, depending on top vel), position & velocity solvers may need adjusting, a physical material is a must. The thing is that the latter opens up so many gameplay possibilities that it’s hard to ignore what it offers.
My experiences with using the projectile movement component were OK, too; but leaning towards mixed. I don’t have a thread or example about that.
edit:
At least the projectiles bounce nicely off one another with this:
Now, if @RichmarIII adds their method, there’d be a nice set of ideas here. Good luck!