Support

It's up to you. I disagree with security headers being handled with plugins, though, for two very important reasons:

1. A plugin is only applicable when a request goes through Joomla. In fact, it is only applicable for HTML requests going though Joomla and only if said request follows through with all plugin events (doesn't exit prematurely). This is not the case for com_ajax, extensions which exit prematurely (e.g. download components, extensions implementing their own JSON API, extensions outputting binary data such as images etc). This means that the protection is VERY limited in scope.
2. All security-oriented headers are meant to be customised per URL. The plugin helps with that but it's not as powerful as editing the header yourself.

In my opinion these plugins are great to raise awareness that these security headers exist but not very good at implementing them in practical terms for real world sites.

We have already added the security and privacy headers that make sense to have an easy to use web interface in the .htaccess Maker:  Strict-Transport-Security (HSTS), Content-Security-Policy (only in the context of SVGs), X-Frame-Options (clickjacking protection), X-Content-Type-Options (reduce MIME type risks), Referrer-Policy, Cache-Control, X-XSS-Protection (reflected XSS protection, deprecated). We have also added the necessary exceptions and customisations that need to go with them so they offer protection while not breaking your site.

We chose not to implement support for the following headers:

• Expect-CT. This will become obsolete in June 2021. Newer certificates have a short validity time and support certificate transparency by default.
• Clear-Site-Data. This is dangerous when used by people who don't have intimate knowledge of how their sites work under the hood. Clearing the cookies or storage might sound like a great idea unless you realise that Remember Me no longer works and any third party component using browser-side storage to remember things (like LoginGuard's Remember Me feature or Akeeba Engage's guest commenter feature) will appear "broken".
• Feature-Policy. This is dangerous when used by people who don't have intimate knowledge of how their sites work under the hood. You might think that you can disable all HTML 5 features your site doesn't obviously use. However, it's easy to disable autoplay and then wonder why your video plugin no longer works. Or you may disable geolocation and find out that your e-shop's payments fail with an error from the payment provider or have a super high possible fraud detection rate. Even worse, you might disable oversized-images and wonder why your background or some of your article images don't work and come to us complaining Admin Tools blocked them (it didn't!). These features should be controlled by people who know what they are doing and do so per URL – which is another problem since Joomla doesn't do canonical URLs.
• The headers you asked about: Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-User, Sec-Fetch-Dest. You will end up in a situation where they get in your way. For example, example.com and www.example.com are two different domains for a browser. Without non-www to www redirection (or vice versa) and $live_site set up in your configuration.php you will end up with extensions doing AJAX requests or trying to load images cross-domain which will be broken by applying these security header. If you are embedding one site into another, e.g. with a frame, these headers may break the pages displayed in the IFRAME. Moreover, these headers make sense and provide actual security when you can KNOW WITH ABSOLUTE CERTAINTY that a specific URL has a specific intent, e.g. that you can only access this URL through interactive navigation and its result will only ever be used in a specific context. Since we're talking about Joomla and a myriad of 3PD extensions this is not necessarily the case. So, you'll end up inadvertently breaking your site unless you are absolutely sure what you're doing and you have the technical capacity to troubleshoot issues like that.
• Content-Security-Policy (CSP). Now, this is something that Joomla 4 does right, implementing it as a component and a plugin because it is necessary to do so! Joomla extensions use inline CSS and scripts. For CSP to be effective you need to disable inline CSS and scripts unless they carry a per-request token or cryptographically signed. The only way to do it is with the help of the CMS itself. CSP can also limit where images and other static assets can be loaded from. Remember the www vs non-www situation I described above? It can be a factor here too. Moreover, you might be loading scripts from external sources (think about payment processing, social media logins / feeds / like buttons, video / audio / image / social media embeds, Facebook comments, third party live chat services and so on) and they have to be explicitly whitelisted. Joomla 4 allows you to run your site in reporting mode to discover all these third party sources and whitelist them before going for full restriction. So Joomla 4 does it right and there's no point reinventing the wheel here.

So, to circle back to your question. Sure, you can use the plugin to set the security headers but be very, very careful. There are too many ways you can screw up your site. If something appears broken disable the plugin and retest. If and only if you still see something broken should you ask us for help in case it's something related to Admin Tools. If you ask us for help and we see the security headers we'll ask you to do that first before spending any more time. Moreover, we won't be able to help you with security headers on your site. If you don't feel comfortable troubleshooting these issues yourself play it safe and don't enable something you can't use :)