There is some special handling in the file display for the way scrolling worked on some Surface (and a handful of other) touchpads. I don't know if the same applies to newer Surface machines.
IMO it's a flaw their hardware/drivers that special code was needed at all. (They do not scroll properly in a lot of software, including parts of Windows itself.) It was a bit ridiculous that we had to add special code for a non-standard scrolling/mousewheel system when we just need normal behavior that their drivers should've emulated via the standard API, especially considering the hardware, drivers and OS/APIs were all made by the same company. But the code is there in Opus now, for when it's needed. I just wouldn't expect devices that need that to be great in all other software, unless they've stopped using that kind of scrolling or have improved their drivers.
That was with touchpads, not touchscreens, so it may well be different on the device you're looking at. The Surface devices seem to be quite different between refreshes.
You're looking at an Intel one but, for anyone else, I would recommend staying away from the ARM Surface "Pro" devices. Windows on ARM is IMO not ready yet. (Can't run 64-bit Intel binaries, only 32-bit; a lot of recent software is 64-bit only. It'll also cause problems with certain features that require binaries to be the same bitness as other software, e.g. shell extensions, some hotkey/automation tools. And the userbase simply isn't there, at least today, to justify many developers buying one of the handful of overpriced machines or spending what can be significant amounts of time adding two more (release + debug) build types to their projects and testing them.)