Snapshot Isolation vs Read Committed - OLTP and Reporting Databases
Just to add to the other answer.

SQL Server supports two different flavors of READ COMMITTED, legacy locking READ COMMITTED and READ COMMITTED SNAPSHOT.  If you've ever built and supported a high-volume OLTP application on locking READ COMMITTED you know why RCSI was introduced (in addition to making it easy to port Oracle applications to SQL Server).

Locking READ COMMITTED is tricky to get concurrency and is prone to deadlocking, as readers block writers and writers block readers.  Deadlocks are a kind of bug in your application, but they're famously hard to find in testing.  So you have a chance to make a choice that reduces the number of hard-to-find-in-testing bugs.  That's worth a lot.  RCSI also increases the concurrency of your application, enabling you to scale up to use multiple cores more easily.  

So, RCSI increases the scalability and reliability of your application, at the cost of a little extra bookkeeping for UPDATES and DELETES (and INSERTS if you have a trigger), and an extra 14 bytes per row.  

RCSI is simpler to program to over all, the main thing is that you sometimes need to opt in to a locking read using the UPDLOCK table hint when you want to read a row and immediately update it and need to ensure that no other session does the same thing concurrently.