I would theorize that the cap sensing library is putting an interrupt on a pin, and without the correct connections, the interrupt wound up firing far faster than it does during normal operation and it was spending all it's time in the ISR.
As an aside... (unrelated to your issue above, but this will complicate things you do with that code in the future, and points to a your not recognizing a common pitfall with serial debugging)
You have Serial configured for 9600 baud (why the hell is this still everyone's "default" baud rate?! It's slow as hell!)
You are printing a string that's something like 15 bytes long, with a delay(10) between each attempt to print it.
9600 baud prints 1 byte in just over 1ms. (10/9.6 ms - 8 data bits plus start and stop bits). So every pass through loop you add around 5 more bytes to the serial buffer than you print. After around a dozen passes through loop, the 64-byte serial buffer is now full (note that you now also have 4 rounds of data backed up in the buffer too). At that point, Serial.print() becomes blocking - it will wait until enough space has been made (through data being sent) to fit what you are printing into the buffer - so it'll take 5-6ms on that step after you've filled the buffer.
You want to avoid printing stuff to serial faster than you're sending it out for this reason; if nothing else, it will make the output you see less likely to lead you astray. In your case, simply cranking up the serial baud rate (or increasing the delay - maybe to 20ms) would solve this. If that's an Uno, I'd just run it at 115200.
On classic AVRs, 115200 baud works fine at 16 MHz (but not at 8 IIRC) - 57600 works at 8 on classic AVRs, and 115200 works on modern AVRs all the way down to 1 MHz (2 if they don't have the version of UART.cpp that uses U2X mode where appropriate)