I suspect what you are seeing is normal Windows PC behavior regarding disk I/O. For possible confirmation I was able to compare two PCs running Windows 7 that have very similar Windows Experience Indexes (indicies?). The first PC is a Thinkpad laptop similar to yours with a P8600 @ 2.4 GHz and 2.5" SATA II 5400rpm drive. The other PC is a desktop with a Athlon 64 X2 dual core 3800+ and 3.5" SATA 7200rpm drive. I would start a local_disk-to-disk copy of a large (several gigabytes) file; while that file copy was in progress I would attempt to start up an application program. The typical delay for both PCs was on the order of 10 to 20 seconds (the delay probably could be correlated to app program size).
Since the desktop PC has two HDDs, I was also able to perform the file copy on one disk drive and then load an app from the other HDD; with two independent disk drives, the apps started in about 2 to 5 seconds.
You mention that this issue also occurs for "network I/O". Unless you perform a single-ended data transfer (e.g. network data to a bit bucket such as /dev/null in *nix), then you probably used a disk file as either the source or the destination to generate "network I/O". So disk I/O reveals itself as the common activity of "disk I/O", "network I/O" and slow startup of apps.
This could be a scheduling quirk in Window: a task that is I/O intensive (such as a file copy) might get scheduling priority when each individual read or write operation does complete (to sort of compensate for the idle time that the process was forced to wait, and to maintain I/O throughput). Another task/process started while this I/O intensive task is active could be at a I/O scheduling disadvantage. I have seen a similar quirk on another operating system: I was developing a database-copy utility on a multi-user system (not Unix). The utility slowed the system down for all other users while it executed, so I was accused of rigging the scheduler or job priorities to my advantage, but I had not.