I read this yesterday and thought your reasoning was sound, but at the same time it seemed unlikely it was in the ref docs for no reason. Just now, a scenario appeared to me where both locks are relevant, but actually this scenario speaks in favor of your approach! If you take a lock on both the property key and the index, in the case of parallel transactions one transaction could get the lock on the property key and the other on the index (hopefully other mechanisms prevent both transactions to fail). If you want to pursue this matter, you will have to investigate which scenarios are covered by tests in the janusgraph gitrepo and try to introduce a failing test.
I also thought about threaded transactions on a single janusgraph instance where in one transaction two threads try to add a name to the same vertex, but that scenario should be handled by the cardinality of the property.