Multi-core CPUs on machines have gotten fast enough over the past few years that in most common application scenarios you don't usually end up blocking on available processor capacity in your machine.

What you are much more likely to block on is the Seek and I/O speed capacity with which your computer accesses your hard drive.  If you are using an application that needs to read/write a lot of files, it is not atypical for your CPU processor utilization to be really low - since the application might be spending most of its time just waiting for the disk operations to complete.

When you are doing development with Visual Studio you end up reading/writing a lot of files, and spend a large amount of time doing disk I/O activity.  Large projects and solutions might have hundreds (or thousands) of source files (including images, css, pages, user controls, etc).  When you open a project Visual Studio needs to read and parse all source files in it so as to provide intellisense.  When you are enlisted in source control and check out a file you are updating files and timestamps on disk.  When you do a compilation of a solution, Visual Studio will check for updated assemblies from multiple disk path locations, write out multiple new assemblies to disk when the compilation is done, as well as persist .pdb debugger symbol files on disk with them (all as separate file save operations).  When you attach a debugger to a process (the default behavior when you press F5 to run an application), Visual Studio then needs to search and load the debugger symbols of all assemblies and DLLs for the application so as to setup breakpoints.

If you have a slow hard-drive, Visual Studio will end up being blocked as it waits for it to complete these read/write operations - which can really slow down your overall development experience.