Thanks for all thoughts on the issue! Some reflections:
Slicer and slicer settings:
The odd thing is I'm using one of Cura's three fixed factory default presets, unchanged. The 0.2mm slicing setting with no changes to it whatsoever. So the slicing really shouldn't be extreme in any way and must have been used millions of times.
The STL file size for the two cylinders is 311kB when the refinement setting in Fusion360's STL "Make" export is set to "medium". With refinement set to "low" the file is 124kB, I haven't printed that smaller file yet though. Would exporting from Fusion360 set to medium be a unusual decision? What do you who are more experienced say, does the STL file size give you any sort of indication if it's normal size or larger than "normal"? (I've just started with this stuff a few weeks ago so I have no feeling for what is large and small)
The GCODE file from Cura with the Cura factory preset for 0.2mm is 1.6MB.
What is the same and what's not between the two Octoprint printed parts? (putting SD card printing to the side for the moment)
So comparing two ways of printing with Octoprint - Rpi 3B+ or much faster HW - shows quite a large quality difference. These two tests where using:
baudrate - identical
usb cable - identical
same 8 bit printer motherboard, well the whole printer is the one and the same
serial driver in the OS, well, Debian was used for both prints but on vastly different underlying USB/serial hardware I guess, so different drivers too probably.
Speed limiting factors with Octoprint/Python/all the stuff Octoprint is doing, yupp, way more cpu grunt and tons of more and faster memory and.. simply much faster HW running Debian in the Intel setup
Still, as you say, I'm seeeing something unusual when running Octopi on the Pi? And what I am having trouble with on this pretty bog standard setup on the fastest Pi is much helped by faster HW. But... why am I seeing this with default Cura settings and a not at all uncommon printer... very very puzzling.