The short version: absent unusual circumstances, you should use a single-threaded traversal. As @CodesInChaos says, your computer is likely to be I/O bound in both phases of your task: size-checking and uploading alike.
Trying to spawn a thread per directory is a recipe for fork-bombing your machine into oblivion. More precisely, there is no point in invoking more threads than are necessary to saturate your performance bottlenecks. Note that there are 2 likely bottlenecks: the performance of your filesystem, and the performance of your network link to Dropbox.
For uploading data to Dropbox, your network is almost certainly the bottleneck. You should easily be able to saturate any broadband link with a single-threaded traversal.
For finding the size of the filesystem, your bottleneck will also be I/O, but the details depend on the actual filesystem. For a solid-state drive, you probably won't benefit from more than a single thread. I suspect that you may gain a modest benefit from a bounded number of threads in a single-disk filesystem, as the OS can potentially schedule head stops a bit more efficiently if it has a queue. The question is, would a small performance margin be worth the cost of implementing and maintaining a more complex implementation? (E.g., handling cases like multiple hard links may be difficult enough with a single-threaded implementation...)
A distributed filesystem might benefit quite a lot from a multithreaded traversal. However, the details of how to extract the best performance are likely to depend on the specific system.
I'm surely overloading it by spawning a thread for each folder that is out there.-- That is not at all self-evident, although it might matter how many cores you have on the server machine. I did write a Windows Service once that did something similar to this; I put all of the processing requests in a queue, and then spun up four threads (it was a quad-core machine) to process four requests at a time, until the queue was empty.