Specifically, what I loose with transactions is fault tolerance and predictable performance while I find I don't really need atomicity in most places.
Fundamentally fault-tolerance is achieved by having few interdependencies among computer systems. Transactions makes that really hard to do for replicated databases and you need replication to be fault tolerant. So usually people cheat and settle for async replication, but then you really don't have transaction anymore since different parts of your system are seeing different states.
Transactions also lead to difficult to debug blocking behavior either due to deadlocks (btw, where else in computer systems is the advice that you have to destroy all abstraction and understand the entire locking order of your program in one place?) or locks getting held too long due to programming errors etc. I hate when my entire site hangs because a key table has locks on it due to some transaction getting accidentally left open.
Understanding database consistency levels and their nuances is extremely difficult and error prone as well. So you may not really be operating in the pristine transactional environment you thought you were.
Finally, programming to a non-transactional model is actually pretty easy in most cases. You just have to go into your project thinking about this upfront. And the decisions you make building a non-transactional site will probably increase how decoupled all the parts are which will make it scale better anyway.