There is nothing there to prevent the HashMap itself from corrupting completely with multiple writers, or from data racing while fetching single items on multiple threads.
So there is no way you can use the ConcurrentModificationException as a way of ensuring that your HashMap is actually working in a concurrent scenario, it only handles one scenario: reads, and even only reads when iterating.
Edit: Ok one reason could be that the documentation sucks and there are no mentions of the concurrency guarantees of the standard library types...
More seriously, it's probably just a frequent mistake and they try to educate people proactively to help code quality in the long run.
Edit: the non-atomic map updates are mentioned in the FAQ, but you're right, the documentation could be improved in that regard (possibly triggering many criticisms of the language from people who've never used it, just browsed the docs for reasons not to use it).