Certainly, with web applications you would want the least amount of latency possible. This is a normal UX scenario -- as you indicated, there are factors which can simply be out of the hands of the application such as network connectivity.
In cases like that, indicating to the user that something is happening makes for a better experience than not doing anything, or in the worst case (which certainly shouldn't happen these days) blocking the user's browser.
Not realy. A user with a slow connection will know that and wait (because the problem will be global). Adding a preloader is just bloat that will make the site load even longer (and just piss off the user as he'll know that some of his scare bandwith was lost on the shiny spinning wheel).
Aside from the reality that a user won't always know their connection is slow / has slowed (particularly when it comes to bad routing between server and client), this is also typically used in cases where you are utilizing XHR.
Given that they're done in the background, the browser won't indicate them being made outside of dev tools. If they're asynchronous, again ideally they will take place as quickly as possible. This is unfortunately not something that can be relied upon.
In cases like that, indicating to the user that something is happening makes for a better experience than not doing anything, or in the worst case (which certainly shouldn't happen these days) blocking the user's browser.