The counter argument is this: there is no benefit to using the property delegate since there are many cases when you have to still be aware of referencing the binding outside the valid lifecycle state.
Your comments about the submitList proves the point exactly. The submitList runnable has everything to do with delegation and view binding since it makes it very possible to reference a binding, delegated or otherwise outside a good lifecycle state. It's too easy for a developer to brush it aside and say "this has nothing to do with it." Even you brushed it aside thinking that it had to do with nullability. It does not.
In the scenario I described, the submitList callback could execute outside a valid lifecycle state. Since a delegated binding is just a property of the fragment it's trivial to reference it in that callback. It's not null and it's a fragment property so there's nothing preventing it.
In that scenario, if you reference a delegated binding then it will fail. (In the delegated case it will crash.) You need to take special action, as you said.
Likewise, if you reference a non-delegated local variable binding it too will also fail. (In the non-delegated case it will leak.) You need to take special action.
Since both cases you need take special action, the delegation offers no benefit.
Both the delegated property and the local variable offer the same level of memory leak protection. However, compared to the local variable, the delegated binding is a non-nullable property that can fool an unware or junior developer into thinking it's self-maintaining and safe to use pretty much any time. It is not.
Even your article fails to call this point out. That's what I meant about the false sense of security. It can make it look like it's safe to just use the binding property because it's this delegated thing that cleans itself up.
Given those restrictions, it's my assertion that a delegated property of the fragment is worse than a simple local variable to, say onCreateView. The local variable forces the developer to think about how that binding is passed around and what the lifecycle states it might be used in are. Yes, I do agree that there's some overhead. You have to pass it down to functions that need to reference it like some sort of manual mini dependecy injection. I reiterate my assertion that cost is virtually nothing and what you gain by doing it is a huge savings in stability and code clarity.
