This blog post is highly misleading. For example, they start off with several paragraphs about security/privacy implications, but this change doesn't have any security/privacy implications. That's because they have explicitly stated that they will not deprecate the observational webRequest API, which has exactly the same privacy considerations as the content blocking API. However because the observational API provides "important functionality for which there is no alternative" (to their tracking business), it will not be deprecated. But the content blocking API which also provides important functionality for which there is no alternative (but hinders their advertising business) is being deprecated.
Furthermore here you can see a tweet from Justin Schuh, lead of security and privacy on Google Chrome, where he claims that the "sole motivation is correcting privacy and security deficiencies" (which I just debunked as being a possibility), not performance: https://twitter.com/justinschuh/status/1134092257190064128
So between Justin Schuh and Simeon Vincent (author of the post you linked), who is lying? It must be at least one of them.
But let's ignore the misleading claims about security/privacy and just focus on the performance issue.
In this post, they include absolutely no numbers or measurements of the performance effects of using the content blocking API. They give some explanation of what is technically required to implement each approach, and certainly the declarative API is a simpler approach, but you made that point already. And I responded to it. Just because the API is "obviously simpler" doesn't mean the performance advantage is in any way significant, and could even be outweighed by the increased ad load due to the less powerful API. It's just not at all obvious from what they are saying here that the change is worth compromising user functionality over.
If you want a source with actual measurements, you should check the Ghostery team's response to the manifest v3 changes: https://whotracks.me/blog/adblockers_performance_study.html
Here are some highlights:
> All content-blockers except DuckDuckGo have sub-millisecond median decision time per request.
> Time to Process a Request in Ghostery (median): 0.007 ms
> Loading Ghostery's Blocking Engine (from cache): 0.03 ms
> Memory Consumption of Ghostery's Blocking Engine (at startup, in Chrome): 1.8 MB
Note that last one: 1.8 MB memory consumption. And they're arguing that we need to be "setting up and tearing down this component as needed" to conserve that "valuable" 1.8 MB. Nonsense.