I fully agree with your statements. The veeam SOBR is not working as we veeam users would expect.
Today one of our SOBR for copy jobs run out of space (per vm jobs, policy data locallity). The copy job already used a second extent because of low disk space on the first starting extent. So you think the sobr works as expected.
But that helps only for a few days. The first extent continues to fill up more and more maybe because of 3 reasons. First of all the copy jobs seems to use another logic for merging the incremental into the full file (see KB2207).
The second reason is that there is no space limit while filling a extent. Often we were told that there is a spare space of 10%, another supportler said there exists a reg key that responsable for the spare size... Nothing of that seems to be correct.
The third reason seems to be the biggest problem in my opinion. There is no space reclamation logic inside veeam that can detect such situations and can fix it. One solution would be that veeam tries to move some full files with their corresponding incremental files from the nearly full extent to another extent with enough space and keep the backup chain and the job intact. At the moment the jobs always retry to merge the oldest file into the full file though there is no space left on the extent. The new incremental files will be placed on another extent with enough space but the merge could never be done anymore.
The only chance at the moment is to start from scratch and create a new copy job and a new backup chain.
We opend support cases many times but had never luck with the support to solve the problems or to place a feature request. At the moment, their is no real benefit of using SOBR. You still have to monitor the repository space and take manually action when the repository is running out of space. We though the introduction o SOBR would solve all of these problems but it was a fake