There are two approaches, use the CiviCRM Starterkit which currently is available as an upstream for Pantheon, or use a fresh CiviCRM install with some patches.
The starterkit is a Drupal distribution will get you most of the way since it includes a few patches so CiviCRM will work more smoothly on Pantheon's architecture. In order to use the the starterkit in Pantheon use the option provided when creating a new site from the Pantheon dashboard (and not from the distribution hosted on drupal.org). Unfortunately, the original maintainer is no longer working on CiviCRM projects so has been unable to maintain the distribution.
CiviCRM with patches
The other approach is to install CiviCRM manually on top of the default Pantheon upstream for Drupal and apply the patches from the Starterkit which patch CiviCRM core. One can then maintain the appropriate patches so they can be applied to each CiviCRM upgrade, similar to the repo "CiviCRM for Drupal on Pantheon" we've maintained for a client (though there are differences currently in what people are patching).
Dealing with a dynamic system
The main change required for CiviCRM to work with Pantheon is get around CiviCRM's approach of hardcoding the absolute paths to all its configuration. Pantheon (and other similar hosts) use environment variables to set the server paths and the database connections. That's because its app bindings will change depending on whether the fallback server kicks in to deal with the load on the site. I've found that this can happen often, especially when a large mailing is being sent out.
First the paths and database connections are set up dynamically in civicrm.settings.php (as described in Kalamuna's post and patched in the Starterkit and the alternative patches). Then one needs to deal with CiviCRM's caching of absolute server paths (at least up to 4.7). For now one can simply bypass the caching of configuration entirely with no discernible downside.
Using Redis for caching and template storage
Pantheon uses Redis caching to improve the handling of the Drupal cache (Redis can handle it better than MySQL). In order to get CiviCRM to also use Redis caching as the default for CiviCRM cache one needs to set up a new Redis caching class in CiviCRM and set it as the default in civicrm.settings.php. This has been merged into CiviCRM core for 4.7. (based on this git repo).
To use Redis for storing the compiled Smarty templates follow the approach outlined in this forum post, which for some has made noticeable improvements to the speed at which CiviCRM loads templates in Pantheon. It can be done by either using Drupal caching functionality cache_get and cache_set or with CiviCRM to store cache in Redis (patch). You may notice some side-effects with using scripts in extern/* folder that don't bootstrap the CMS, so you may find these patches.1 2 useful (for PaypalPro).
There are a few other minor patches as part of the Starterkit but these main ones will get you a long way to a stable and efficient CiviCRM on Pantheon.
By default Pantheon runs cron once an hour. In order to run cron more often, which is useful for more granular control of CiviCRM cronjobs (also useful for Drupal's Elysia cron), one needs to use an external cron or ping service.
Emails and SMTP
For basic Drupal setups on Pantheon just using their email service for sending basic transactional emails is okay. But it is highly recommended to use an external SMTP service for emails on CiviCRM (and for Drupal). CiviSMTP and Mandrill (with a CiviCRM extension) will work for Civimail and CiviCRM transactional emails.
Benefits of CiviCRM on Pantheon
As others have noted, being able to quickly clone the site into a new branch with MultiDev, or even just clone between the default environments, can be a big time saver for small development firms and for freelancers without the knowledge or support of building a similar system.