In other words, he thinks companies avoiding potential license infection of their closed-source code is not the main reason. To be clear, the author believes in the promise of AGPL and thinks the real issue is the payment structure. Excerpt:
>So we're going to build on the idea of dual licensing. You know – licensing under both AGPL, which is rather unfriendly to commercial applications and another separate commercial license. In my opinion, it is a very promising funding model for many projects, with one problem: it does not scale.
Let's consider Google's ban on AGPL as one example: https://opensource.google/docs/using/agpl-policy/
Thus, using author's framework, we'd interpret Google's ban as merely avoiding too much licensing paperwork (too many software contracts are not scalable) and that they actually have no intellectual property problem with AGPL.
Basically, it seems like he's proposing "AGPL"-collective rather than AGPL-multiple-custom-contracts. The philosophy of AGPL is still a crucial part of his proposal. In his view, once the AGPL-collective is in place, the main reason for the Google AGPL ban would no longer be there. Excerpt:
As an Open Source developer, you build a new cool library or a tool and license it under AGPL. This preserves all the Free Software freedoms for all the non-commercial users out there. You don't have to compromise on it. Debian and Brew can still ship them. Then you go to one or more FOSS Collectives and sign a licensing deal
He's saying programmers don't have to compromise on ideals of AGPL -- just give commercial companies an easier way to pay for it with a one-stop-shopping experience for the license.