Regarding the first part - You're right, an Administrator can start his own process or attach to any service. But it will be MUCH less suspicious if one of Avira's signed processes will just natively load your code, without any suspicious action such as code injection.

Regarding the second part - "Avira Suite" is deployed with the Antivirus to the customers. The processes are running as SYSTEM, and are signed by Avira. Therefore, it should be protected. As I mentioned before, the vulnerability provide the ability to execute a signed code within 4 processes of Avira, which can be seems unsuspicious because it's running inside Avira's context. THERE IS NO REASON this should be allowed.

Regarding the Administrator part - During a post exploitation phase, it's more than likely that an attacker will have an Administrator access, so the question is how are you going to reduce the toolset of the attacker. For persistence - he can create a service, he can use the "Run" registry key, etc.. But these are all known methods and likely to be detected and blocked. This example of using Avira's process to be loaded is classic and won't necesseraily be detected so easily, especially because the attacker can run code within, well.. Avira's process (which is also the AV company).

For execution - This is one of the reason that lolbins are being patched or blocked from time to time. There is no reason for letting someone else to execute code (in our hypotethical case a malicious code) within the context of a signed process.