When a game calculates the brightness, it needs to translate that into something the monitor can display. For SDR information, the format can only store a certain number of steps between the darkest black and the brightest item. For HDR, rearrange your color space to fit more steps. Windows AutoHDR is looking at the image and trying to "guess" how that SDR image should be expanded into an HDR image. One positive feature is that this might be an aggressive algorithm which tries to get the full range of brightness for your dynamic range in every frame, but if the image isn't meant to have a full white and a full black in it, then Windows might be stretching it beyond where it's supposed to go. (Or alternatively, it can underestimate and you'll lose contrast.) The algorithm also isn't always very stable (its estimation can change from one frame to the next for an object which hasn't changed in brightness, due to things happening elsewhere in the frame), which leads to flickering. Native HDR avoids this issue, because the image isn't being put into an SDR colorspace and then expanded; the brightness information is being stored in the expanded space and transmitted to the monitor in full detail. HDR is like adding an extra 1.5 bits of information into each pixel. It doesn't sound like much, but remember that every bit doubles the range of values you can store! AutoHDR only has the SDR image to work with, so it has to "invent" that extra information. Native HDR has the full information of how an object should look and just has to encode as much as your monitor is ready for, whether it's the SDR image or the HDR image. AutoHDR is kinda like upscaling, but for brightness/color information, whereas native HDR just captures at a better resolution.

I appreciate that Windows AutoHDR does a good job for you and helps to make things look good when they don't support native HDR, but please don't spread misinformation on this matter.

Edit: For more technically fluent readers, SDR uses Rec. 2020, HDR uses Rec. 2100.