Sorry, but I honestly think this is really dangerous advice. You should use transactions when you need to group read and write operations into a consistent, atomic operation, for example most http requests to an application server. In some circumstances, SaveChanges() might be enough to satisfy your requirements, but most non-trivial usages of EF require multiple calls to SaveChanges(). Requiring each logically atomic action to only call SaveChanges() a single time will eventually become impractical to maintain and makes it impossible to integrate with anything that uses SQL without EF. Many applications are (justifiably) architected to use many EF Contexts (which are designed to be lightweight) within a single transaction. Data integrity also often requires guarantees that the data that you've READ has not changed before you alter it, something that requires transactions for (or EF's Optimistic Concurrency, to a much lesser degree). In short: SaveChanges() is not a full replacement for transactions.
The serializable transaction level IS usually overkill (and the fact that it's the default is annoying), but it's trivial to change it. Finally, the circumstances where you would most likely see deadlock problems, on highly-concurrent read-write databases, is where it is most critical to have proper transactional semantics to maintain integrity. Deadlocks suck, but are easily avoided with good data models and proper use of transactions. It is also preferable to end up with a rare deadlock error than inconsistent data.
Sorry, but I honestly think this is really dangerous advice. You should use transactions when you need to group read and write operations into a consistent, atomic operation, for example most http requests to an application server. In some circumstances, SaveChanges() might be enough to satisfy your requirements, but most non-trivial usages of EF require multiple calls to SaveChanges(). Requiring each logically atomic action to only call SaveChanges() a single time will eventually become impractical to maintain and makes it impossible to integrate with anything that uses SQL without EF. Many applications are (justifiably) architected to use many EF Contexts (which are designed to be lightweight) within a single transaction. Data integrity also often requires guarantees that the data that you've READ has not changed before you alter it, something that requires transactions for (or EF's Optimistic Concurrency, to a much lesser degree). In short: SaveChanges() is not a full replacement for transactions.
The serializable transaction level IS usually overkill (and the fact that it's the default is annoying), but it's trivial to change it. Finally, the circumstances where you would most likely see deadlock problems, on highly-concurrent read-write databases, is where it is most critical to have proper transactional semantics to maintain integrity. Deadlocks suck, but are easily avoided with good data models and proper use of transactions. It is also preferable to end up with a rare deadlock error than inconsistent data.