Actually, not calling dispose on an IDisposable does not guarantee a leak of native resources, and this has never been a "norm" in .NET. Classes implementing IDisposable usually have a finalizer that is called when the GC eventually cleans up.
This assumes that the GC can in fact do its job, which it can when the reference cycle involves only .NET objects. It then has the ability to walk the object graph and prove that there are no "root" references left - and can chuck away the whole cycle. However when you cross the border to WinRT so that one object is managed and one is native and they both refer to each other, you're stuck. The GC can no longer detect the cycle and therefore cannot run finalizers and clean up.
So it's not a question of deallocation being delayed. It just won't happen. (!)
And to reiterate, we do think users should dispose, to ensure deterministic deallocation. I fully agree, it's crucial in memory constrained scenarios. But that's slightly different from requiring a call to Dispose under the penalty of leaking memory forever.
We basically chose the lesser of two evils.
And again, in the wrapping pattern shown by CustomEffectBase, the "weakness" can be hidden rather naturally.