Quite a few very high profile/traffic sites have switched over to static site generators like Jekyll and Octopress. However, while there are some performance, deployment and security benefits to a static site, there are also a lot of drawbacks. There is a reason why most sites on the web today are dynamic, and why most CMSes aren't static site generators.
The main drawbacks you need to consider are:
Site generation time
There's no such thing as a free lunch. Static site generators don't get rid of the page-generation and processing that conventional CMSes do; they simply divert this task to a different time/place. The same work still has to be done, but instead of splitting that work over hundreds or thousands of requests, the generator does it all at once. This may save your visitors precious milliseconds, but it can really add up in site generation time.
As your site grows larger (or if you're converting a site that already has a significant amount of pages), your generation times for things like making layout changes (nav, heading, footer, sidebar content, etc.), generating tag or archive pages, etc. starts to take more and more time. I highly recommend reading this webmaster's account of his switch before taking the plunge yourself.
So if you have a large site that depends on timely updates, you may need to get rid of features like tags, related posts, archive pages, etc. so it doesn't take you an hour to generate the site each time you make a post.
Luckily, if content update lag time doesn't affect your site, you can probably automate the process such that your content writers simply submit their posts to an update queue, and the update script handles the site generation in the background unattended. It may still take an hour before the post is up, but it's not wasting anyone's time.
Static sites are very limited in functionality
You can embed non-static components into your site, but this gets rid of many of the benefits of running a static site, and it also requires you to manage your site from multiple locations. And some features simply can't be provided via an embedded SaaS service, e.g. live content management, JS-free + search-engine-friendly comments, user management, etc.
Other features, like faceted search, dynamic navigation (e.g. most popular posts, recent pages, community tagging, etc.), web services (SOAP/XML-RPC), session management, etc. become really difficult and awkward to implement. Basically, you should be sure you don't want to extend your site beyond a basic blog.
Luckily, however, most blog sites can have their core features implemented on a static site. So the drawbacks aren't as serious as for other types of sites (e.g. community or membership sites, e-commerce stores, etc.); so it's really just about weighing the costs vs. benefits. There isn't really a right or wrong answer here, and it depends as much on personal preference as it does site requirements.
However, if your main motive for switching to a static site generator is performance, you should probably first explore other options like:
- offloading static assets to a lightweight web server like nginx + a cookieless domain
- using full-page caching (which after the first request for the page will essentially be like having a static page)
- query caching so that DB requests happen infrequently
- using client-side caching
- consolidating resources to minimize HTTP requests
- increasing parallel downloads
If you set up the dynamic site correctly, it could potentially be faster-loading than a static site that uses a bunch of 3rd-party JS embeds for things like comments, trackbacks, etc. So as john suggests in your comments, you should actually benchmark your site and find out where your true performance bottlenecks are. It may be that a CDN or CSS/JS consolidation would have a greater performance benefit for your site than switching to a static site that adds even more linked JS & 3rd-party dependencies.