How to post-process G-code to make prints faster using splines and arcs?
I would have liked to answer linking to credible official sources, but I cannot add references either on direct B-spline printing. So I'm writing down my thoughts. I've familiarized myself in B-splines to understand what they are and read into the 2 references given by the OP.

Basically, the printer software only allows printing of straight lines. Yes I know we can give orders to the printer to print a curve (using G2 or G3), but these eventually will be converted to printing straight lines. There is no ready made printer firmware available to print cubic curves directly to my knowledge. If it would be possible, these curves should eventually be translated into smaller straight lines by the firmware of timed stepper rotational output. These extra calculations would demand a considerable effort of the printer board processor, most probably far more an 8-bit processor would be able to handle.
Comparing the paper released in 2017 to the G-code pre-processing software reveals that although both seem to refer to B-spline techniques, they are implemented differently. For example, the pre-processing software aims to reduce the linear travel moves by replacing these with B-spline curves (and not affect the actual print object), while the paper focuses on the optimization of the actual printing curves being optimized by B-spline curves (also using a pre-processor). Both eventually would need to create a multitude of small straight lines to have the printer be able to actually print the object as there is no 3D printing firmware solution to print curves. Do note that the method in the paper has been questioned by the RepRap community, which demonstrated that they could print the same object way faster than the B-spline optimized example. Furthermore, do note that the Marlin community is probably moving in that direction as can be seen from e.g. this feature request and this G-code meta overview; G-code instruction G5.
So, both methods rely on pre-processing G-codes by identification of sliced coordinate (print) moves, translation into Bézier/B-spline curves for (print) moves, which eventually are translated into normal G0/G1 (print) moves. It does not appear that the Marlin community/developers are aiming to implement Bézier or B-spline curves soon. This implies that if you want to pursuit printing B-splines, you need to make your own pre-processor, or dive into Marlin C++ development; an 8-bit based printer board would not be sufficient indeed like the OP mentioned, up-scaling to 32-bit or interfacing with USB might be the only solution.