The cancel button technically doesn't delete anything: it performs a rollback which returns the object in question to the state it was in the last time it was committed. As a new object has no previous commits, it ceases to exist.
Now the cancel button isn't very smart. It has no idea where or how your object is saved. All it knows is that, when triggered, it should roll back. So the fact that your commit microflow is triggered in the same form as the cancel makes no difference, the commit still took place before the cancel event so your object will still exist after cancel.
The custom cancel activity is definitely a possible way to fix this. The downside to this approach is that it ignores the scenario where a user triggers your commit microflow but leaves the page without clicking cancel (e.g. by closing the browser). An alternative is to postpone any reference changes you want to make to a before commit microflow on the data view object.