The author mixes up 'open core' with 'dual licensing' (specifically dual licensing with FOSS and proprietary options).
'Open core' is having some FOSS product, and selling additions to it, that are not FOSS. Open core tends to be problematic since the motivation is to keep the open core limited, so you can sell additions to it. But the community can fix those limitations by writing FOSS code. So there is tension there.
'Dual licensing' is having a single codebase, and making it available under several options. One approach there is to offer a FOSS version, typically GPL, alongside a proprietary license. So you can use it under the GPL, or you can pay for a license and use it without opening up your own code.
Obviously there are some similarities between 'open core' and 'dual licensing'. But the main problem with 'open core', mentioned above (the tension between keeping the core limited, and the community's desire to improve it) does not exist with dual licensing.
I'm not saying dual licensing is great. It has downsides as well. But the author talks about these two very different things as if they were one.
It looks like Canonical is positive about dual licensing. I don't see much a problem with that personally. If they were going to do open core, I'd be very annoyed.
Note that dual licensing is also separate from requiring copyright assignment (which Canonical does). Copyright assignment can help with dual licensing, as you own the code, and can offer additional licenses of it. But, there are other ways. You can allow community members to submit code under a permissive license which is compatible with the copyleft one. That doesn't stop you from offering a proprietary license to the code you own.