This addresses some of the hassle around buying multiple tickets, but does not address the inherent privacy issues. But there are still some problems.
First of all, this remains a hassle in most countries, since handling a national identity number (if such a number exists at all) is restricted by law. Even in some countries that do not legally restrict collection or storage of identity numbers (AFAIK the US does not restrict private sector usage of SSNs), there is rarely wide acceptance of providing your identity number for any purpose other than official government services and financial institutions. This means that in most cases, the event organizer has to resort to more traditional methods of KYC: Requesting some personal details (e.g. full name and birth date) and requiring to present an identity document that carries the details above. Verifying the identity document adds slows down entrance lines and increases the cost.
The other issue with this method is privacy. You're still not breaking the suggested BAP (Bots-resistance/Accessibility/Privacy) theorem suggested by the article. Additional personal information has to be collected and stored until the time of the event.
But I believe there is a way out of this. You can still create a limited resource that is more restricted than phone numbers or credit card numbers, and can be optionally verified at the venue cheaply. The only problem is that would require cooperation from the government (and a great deal of effort if you want to make it perfect). The government needs to already have an online digital KYC method that is bound to your digital ID or an online government account. Then the government can use that method to provide an anonymous federated login that provides a unique ID that cannot be traced back to any national identity number. This is essentially how Sign in with Apple works with "Hide My Email" selected: No personally identifying claims are included in the Open ID Connect ID Token and "sub" is unique (per Apple user + 3rd party service combination), but not traceable back to the the original Apple identity. Unique identities can also become ad-hoc per-event (instead of per ticket provider), which makes them completely private (ticket providers cannot track users across multiple events).
At described above, this service still only provides a limited resource akin to phone numbers. For events where the profit margin from ticket scalping exceeds $100, you could still get some scalpers who'd convince collaborators to identify in with their government account and buy tickets for the scalper for $20 per ticket. If you can get 5 tickets per ID, that's $100 of easy money for 5 minutes of work. You can add simple and fast verification at the venue by requiring the users to generate a QR code that is tied to their unique ID at the venue in order to enter. The QR code cannot be generated in advance and is based on a challenge QR that is presented at the venue. This requires collaborators would have to physically come to the venue or be available at the time the scalper's agents come to redeem the paper tickets at the venue. With a QR code generation and check directly at the gate, scalping is completely impossible (at the cost of longer lines and less entrance flexibility). With printed tickets the scalper needs to send agents to physically collect the tickets and communicate with the collaborators (who need to be available at the day of the event to generate the QR codes remotely) — which greatly inflates the cost of scalping.
Even when you get governments to cooperate with this approach, there are still some holes with this approach. The first issue is that eKYC needs to become popular enough to avoid a large loss in sales. The second issue is raising awareness with regards to privacy-preserving eKYC vs. regular eKYC. This two services look very similar (you log-in with your government account or ID to prove your identity), but the scope of the information shared couldn't be more different. Normalizing eKYC carries the risk of people becoming careless about divulging private information. Luckily, this could easily be solved by governments restricting private sector parties to which full eKYC is provided based on their callback domain names and registered credentials (like OAuth client ID and client secret).
The last problem is the probably the most complex one to tackle: how would you accommodate tourists? After all a lot of the venues sell a large share (or even the majority) of their tickets to tourists. I can think of two possible answers.
The first approach is to fall back to a manual passport-based KYC process for tourists. Tourist ticket buyers would have to enter their name and passport number in advance and the passports would be verified in person at the venue. This can be slightly sped up with automatic passport scanners if the venue has a high volume of visitors that warrants the costs. This approach seems to be where China is going: the resident ID card is used for entrance to many places and even for buying railway tickets, but tourists just use their passports. This works well when the percentage of tourists is low, but at a venue which expects a high number of tourists you'll run into all the issues I've described above.
The other option is probably more of a pipe dream, but it would be nice if countries could issue a temporary (and restricted) eKYC account to visitors when they complete their ETA. Even countries without ETA can still offer a pre-registration system just for obtaining an eKYC account in advance. This eKYC account can be used to purchase tickets in the destination country in advance, but it would only be activated for generating gate QR codes when physically entering the country with the matching passport. The main limitation of this approach is that you must first obtain an ETA before purchasing tickets, but you'd usually already have concrete travel plans by the time you're purchasing the tickets.