When you drag things with the mouse, Scribus - and all other applications - has to try and convert that movement into the Unit Of Measure used by the application and that's where things get a bit complicated.
Dragging something with the mouse creates an event that tells the application that the mouse has been dragged. The application must then interrogate the mouse drag event to see if the drag amount was sufficient for the drag to be reflected by the UI. If that is so then the application needs to update the UI as appropriate.
Drag amounts in the event are measured in pixels but, since Scribus doesn't use pixels as a UOM, the amount of drag has to be converted to the document's UOM with regard to the current level of zoom. Because of this, there will naturally be some "granularity" of any drag where the document UOM doesn't accurately line up with the pixels of the screen.
After an application has converted the drag amount to the document's UOM it also has to convert the measurements back to a pixel value in order to know where to redraw the thing being moved. If that pixel value is not a whole pixel, the application has to make a guess at which pixel to use, e.g. the one to the left or the one to the right. Because of this, not every drag action will be smooth. This can be more pronounced when a document is zoomed out as more space in the document is "squashed" into the same pixel on the screen. It also depends on the accuracy of the measurements and conversions being used by the application. Some applications are more accurate than others.
With Scribus there's also the added complication that you can configure the display size - via Preferences/Display - and not everyone will have done this properly.
Normally this isn't a problem but it is sometimes. I've probably not explained this very well but hopefully it will make some sense.
All-in-all, as mentioned above, it's better to use guides, snapping and the "Align and Distribute" functions to arrange things rather than trying to line things up manually.