There's more to virtual memory than just "apps allocating RAM and when physical RAM runs out, something gets paged out to SWAP".
In Linux (and possibly UNIX at large), the system tries to keep pages recently read in RAM: programs executed, data loaded, data recently written (already on disk too) etc. So that if the same program gets executed again, it doesn't have to get re-loaded from the disk. When some program asks for more memory to be allocated to its virtual address space, first the left-over disk buffers are re-purposed (without disk access). If this is not enough, some pages of running apps, that have not been accessed recently, get actually swapped out.
On Linux, swapping normally doesn't happen at all. Once your system starts swapping, you notice the increased drive activity (and sluggishness) and you go "oh what the f.." because it probably means that some app is leaking memory, or something under the hood has started spawning out of control.
Windows traditionally have a stupid additional habit, that they swap out whole user-space apps after some timeout on their inactivity. Strictly, without a pardon, just to have as much RAM available as possible, "just in case" you wanted to start yet another hungry app. If you leave your PC running, and you go away for a few hours, upon your return you notice that any app you switch into, it gets sloooowly reloaded from the swap.
This behavior was particularly painful in Windows 2000 and is getting gradually less noticeable in more modern Windows versions. In W2k, turning off the swap was a no-brainer. Windows 7 can still ooze like honey sometimes for no particular reason, Windows 8.1 and 10 got noticeably better... but still there's no tweakable knob for "swappiness", or other tuneable parameters of the swapping algorithm.
There are other factors that can lead to the system grinding along slow disk access. In Windows 7, you never know if the system has just swapped out your app in the good old W2k fashion, or if you should blame the Antivirus for the fact that your app is starting so slow, or if it's Windows Update doing something in the background this time around (known to have reciprocating quirks in its algorithms that lead to hangs with 100% CPU consumption and/or disk thrashing), or if specifically some .NET Framework janitoring task got lost in the WinSXS database or what. On occasions / in some Microsoft software versions/incarnations, it actually seems that some windows-native "in the background tasks" (specifically Windows Update local database management) are deliberately "obscured" in the task manager, their CPU and RAM usage does not show in the total memory consumption. "Legitimate" activity, but pretty difficult to distinguish from a malware rootkit... Only once the thrashing stops and a balloon saying "new updates are available" instantly pops up, you know what the reason was.
Well at least the recent Windows versions can tell you disk IO activity per process, and individual services are now reported separately (instead of a single SVCHOST.EXE process).