The fundamental issue with scrolling is that, unless your hardware does it for you, it involves moving around the contents of your whole video memory. In other words, scrolling is the type of video programming task that is mainly limited by your system's fillrate. And, unfortunately, the fillrates of the majority of retro platforms are not particularly good.
A video memory size on ZX Spectrum is 6912 bytes (this is bitmap + colour attributes together). The fastest way to copy on Z80 is about 12.5 t-states per byte. ZX Spectrum has 70K t-states per single video frame. Thus, one cannot copy more than 70000/12.5 ~ 5600 bytes per frame. Therefore, most smooth scrolls you'd see would be done by filling i.e. constantly re-drawing pre-generated content. Filling is possible at 5.5 t-states per byte, hence, it at least gives you a theoretical chance to fit into a frame.
I keep talking about frames because the only way to get truly smooth scrolling is by updating your screen every frame, at 50Hz framerate. The challanges involved into this are such that during the commercial life of Spectrum, I am not aware of a single 50Hz scroller released. Zynaps was famous for 25Hz updates (which were sometimes slower than this). There were several other scrolling platformers at 25Hz, each considered a massive engineering feat. R-Type runs at 12.5 updates; I never measured the frame rates in isometric games, but I can guarantee that they will not run faster than 12.5-18.7 frames per second. It is simply impossible to do it faster due to the limited framerate of the platform.
Now, the reason why I gave you all these numbers is as follows. Amstrad CPC has the same CPU as ZX Spectrum and 16Kb video memory. Essentially, Amstrad CPC has a similar fillrate and twice as large screen. Thus, any code trying to work with video memory as originally designed for ZX Spectrum is going to be automatically delayed by a factor of 16Kb/6.75Kb > 2. Zynaps slowed down by a factor of two would only be as smooth as R-Type was on Spectrum; R-Type, not an icon of smoothness by itself, would become properly jerky if slowed down this much.
Of course, modern demoscene for Amstrad CPC shows that some of the fillrate issues can be addressed by getting help from the video chip. I believe that, for example, people can generate repeated scanlines, so that only half or quarter of scanlines would need to be actually updated. This would tilt the fillrate balance into somewhat more tolerable situation.