The notices are coming from the DTM library, not from Adobe Analytics.
To function properly, the DTM Header script must be placed directly on the page as a script tag, and must not have deferred or async attributes added to it. If you follow their recommendation to add those attributes, or otherwise dynamically append the Header script to the DOM, you will break DTM and Adobe will not support your implementation. DTM does not have an async implementation of its library, and that's all there is to it. Live with it or move to a tag manager that can be deployed asyncronously (e.g. Adobe's new tag manager Launch)
Further, some of those notices are likely coming from how you have deployed certain tools or tags within DTM. In a page load rule, if you select for it to trigger at Top of Page or Bottom of Page, then DTM will output code related to tools (e.g. Adobe Analytics) syncronously, and also any 3rd party tags specified as Sequential Javascript or Sequential HTML will also be output syncronously. Depending on your implementation needs vs. limitations of whatever tags/code you have in a given rule, you can change this aspect of your implementation, by switching to Trigger at DOM Read or Window Load, and changing 3rd party tags to Non-sequential.
Overall, one thing I will note is that tools like this Google page insight or similar, that try and evaluate your site and make suggestions to improve performance, should not be 100% relied upon for making decisions. In a perfect world, everything would be loaded asyncronously at the bottom of the page. In practice, this simply isn't feasible to do many times. You have a website that may contain hundreds, thousands of moving parts. Many of those parts depend on each other in many different ways. Load / execution order is a very important issue for those parts and you don't have a lot of options for controlling that order, especially when you are working with different tools/scripts from different vendors hosted in different places.
This becomes even more critical when you start dealing with UX stuff, like AB/MV testing. Showing a visitor a designated experience is critical to protect the integrity of AB/MV tests, but this technology is fundamentally at odds with async philosophy. BEST case scenario is UX takes a blow with "flickering" while alternate AB/MV content is loaded async, and that's not good at all. That is not to say that these challenges cannot be overcome. I have clients who opt to do things like show a loading splash screen with clever sprites. It's not ideal but it's better than having the user stare at a page that looks like it's having trouble loading. But even then, there is only so much you can do with all this. Especially when it comes to integrating 3rd party tools with each other. Many tools out there simply don't have stuff baked in like load callback functions to chain things together, etc.
Site performance / optimization tools are useful as a benchmark / guide, but don't let them become the full/final authority for how your site is structured or how things are deployed on it. It is "an" ideal to strive for, but in practice, a vast number of tags, scripts, libraries, etc. (not just analytics/marketing related) simply aren't there yet, and some of them are useful tools for your organization but fundamentally go against that ideal (which isn't a bad thing - it's just a different train of thought/approach).
But I guess the TL;DR here is if you really are striving to get rid of all those notices and get a 100% mark from your performance tool, then you are going to have to move away from DTM and use something else like Launch, GTM, or Tealium, which can be deployed asyncronously. In general, you will limit yourself to what you can actually deploy through them, though. But I don't know how this actually affects you in practice, as I don't know what all you currently have deployed in DTM.
