Releasing all the locks you've successfully acquired and then waiting on a different lock — even without a back-off sleep, although I think that would be a good idea after repeated failures — is expensive. It would be foolish to do all that just because one of the try_locks failed spuriously because of a scheduling event. The benchmarking will of course not show that because the actual mutexes are platform mutexes, and as Jonathan shows in the proposal, nobody actually implements try_locks that fail spuriously.
Now, one use case I can imagine for a weak tryLock would in fact be in a std::lock implementation. You would lock one of the mutexes and then try to weak try_lock all the rest. You repeat that residual loop on the remaining mutexes until you stop making progress (i.e. successfully locking at least one new mutex). At that point, you make one last attempt to lock all of the mutexes, this time with a strong try_lock, and only if that again fails to make progress do you back all the way out and restart by locking one of the mutexes you failed to acquire. I do think it's quite unclear that a weak try_lock would be a practically useful optimization here, though. Testing for spurious failure is pretty cheap.
I think you're right that the committee was only thinking of std::lock, although I don't think that's much of a defense.