"Loading" screens, progress bars, spinners, or the like are necessary for operations which take enough time that the user needs reassurance that the program hasn't crashed or become unresponsive. For shorter-duration operations, a spinner or loading screen can actually increase the perceived duration (if not the actual duration) of the delay.
There has been a fair amount of research on perceived performance, including how the design of a progress bar can affect the perceived delay (a "backwards moving and decelerating ribbed progress bar" was perceived in this study as 11% faster than actual time, for example) -- but in general Jakob Nielsen's rule of thumb is still a fine one: at 1s the user may start to wonder if something has gone wrong; at 10s they are likely to abandon the task. Therefore don't show any sort of loading or progress bar for <1s, and blocking the UI for more than 10s should be avoided if at all possible.
(That said, 10 seconds is a long time; if there's any way to push a lengthy operation into the background rather than blocking the UI, do so: let the user continue with their work and notify them when the operation is complete, instead of forcing them to stare at a spinner for the full duration. The exact amount of time at which this becomes worthwhile depends on the specific task and how long the user would expect it to take, and on implementation details: for example single-page-app frameworks make it relatively painless to background operations via XHR and notify when ready, compared to more "traditionally" structured applications.)
If the implementation of your loading screen overlay is such that it would be difficult to introduce a delay before it appears, a near-trivial solution is simply to add a CSS transition to the overlay that keeps it transparent and offscreen for the first 1s (using for example
@keyframeing the opacity from 0 only after a second has elapsed). For short operations, the element will still be drawn, but will be invisible to the user until it's been kept around long enough to be necessary.
Mobile vs Desktop
You assert a couple of times that the user experience of a loading screen is different on mobile devices:
...the quick flash can happen on mobile devices too, but there is less distracting because the screen is smaller and users are more used to full-screen loading modals on such devices
I'd be very wary of your conclusions here: a distraction is a distraction, regardless of the size of the screen; and "users are more used to it" is tantamount to saying "Others give mobile a substandard experience, so we can get away with doing that too". The distinction between mobile and desktop devices is getting smaller over time; the form factor is different, but the capabilities of the device are at about parity, at least as far as the average web app is concerned.