For data that’s been cached, the two caches should perform equivalent. In general, most folks will find that WP-Supercache is easier to setup and use from an admin perspective (purging & pre-populating).
People cache for two reasons:
1) Improved concurrency at handling many visitors simultaneously. This is only relevant to high-traffic sites. For this, both technologies can perform similarly.
2) Faster time-to-first-byte by pre-compiling the results. This is relevant to all sites, regardless of how much traffic. WP-Supercache can perform better here because it’s easy to pre-populate your cache.
Nginx FastCGI cache just caches the output of WordPress to disk so that requests that match the cache are immediately served by Nginx without hitting the PHP interpreter at all.
WP-Supercache does something similar; however you have to adjust your Nginx Vhost file to tell Nginx where to find the WP-Supercache files. If you do this, then performance should be equivalent.
Otherwise Nginx passes the request to PHP, which then retrieves the files. It’s still significantly faster than hitting MySQL and compiling the result in PHP, but not quite as fast as skipping PHP entirely.
WP-Supercache does a little better job at integrating with WordPress so it’s safer to tell it to cache results indefinitely and then manually purge the item when it’s updated, versus with FastCGI cache the default is cache items are purged after 10 minutes.
On the other hand, FastCGI cache can cache non-standard content, such as 301 redirects generated by your PHP app and 404 errors.
If you ran a really busy site, you could also run both caches together, probably making FastCGI cache not cache typical pages/posts since that’s already cached by WP-Supercache, but caching 301, 404, etc.