Bad implementations are indeed rife! It can be particularly problematic in home-grown ORMs. ACID DBs do provide you with tools to work around this pretty easily, but it's fair to say a lot of mistakes get made.
It's one reason I'm wary of anti-ORM sentiment I sometimes see around. I'm quite often more productive when I eschew a heavyweight ORM in favour of something closer to the 'metal', but part of that is that I have a lot of background in database systems, so I'm confident that I will generally avoid concurrency mistakes. For a typical programmer, in a developer culture that doesn't want to understand the complexities of data storage, my experience is that they're often better off using an ORM.
Say for example you have two users on a normal CRUD app. User 1 opens an object in a web form. User two opens the same objects a few seconds later.
User 1 updates field A. Saves the object back to the database.
User 2 updates field B. (field A is still in the web form at its initial state). Saves the object.
Field B is at the correct state, but field A is not.