This describes an
opportunity for a web page to trigger behavior in a native application that it has no relationship to by springboarding through an extension paired with that native app.
The threat associated with that opportunity will depend on what the native application does with received messages.
In the example case the native application presumes the content of a received message is safe and uses it to load an arbitrary DLL by path. And yes, in that case, you'd need to anticipate the path to a malicious (or insecure) DLL and that DLL would have to be executable in the user's environment. In this example, it's actually the native application that's failed to be written defensively (it should only load DLL's that it already knows about, not arbitrary ones hinted by a path from the extension), but this is really just a random example.
You could alternately imagine some other native application that was made to be very fancy and dynamic and comes with a script engine of its own, that 'eval's messages received from its extension because it (likewise) presumes its safe to do so. People do foolish things like that.
Or you could imagine the GetCertLib example letting someone quietly trigger a malicious DLL that they delivered through some otherwise legitimate-seeming means. ("Ah, the targeted user has confirmed their identity by logging into our website... time to trigger the payload we included in Silly Solitaire")
etc
The point is that the article is not about what that native application does when receiving a message, it's about the ability for an unaffiliated web page to make a native application do something, which is limited only by how poorly or insecurely designed many of these native applications can be.
Browsers seek to thoroughly safeguard against this kind of escalation, but have left a window of opportunity here. That's what this is describing.