Is dirty-read a problem in an always-commit database?
If you still allow transactions that span multiple statements, you would still potentially have dirty reads.  

Imagine that I have a simple banking application where session 1 is trying to transfer $100 from account A to account B.  Session 1 starts a transaction and subtracts $100 from A.  Now session 2 runs a report that tries to make sure that money hasn't gone missing (which is somewhat useful if you are running a bank).  If session 2 is allowed to read the updated balance from A and the un-updated balance from B because session 1 is in the middle of a transaction, it has done a dirty read.  The fact that session 1 is going to eventually commit the change does not change the fact that session 2 was able to get an inconsistent view of data.

Of course, a database that disallowed rollbacks but allowed transactions that spanned multiple statements would be rather problematic.  If I subtract $100 from A and then try to add $100 to B but I encounter an error trying to update B (perhaps I discover that there is a hold on B or that B has been closed), I'm in a pretty unfortunate position.  Assuming I don't want $100 to disappear into thin air (which will make A rather unhappy), my application has to catch the exception and manually implement a rollback by putting the $100 back.  In real applications where transactions involve changes to a bunch of different tables, some of which are done by triggers that the application may not be aware of, that is a non-trivial challenge.