I am guessing he means the applications built on top of them.

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.

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.