Why are almost-blank ._ files being created by macOS and applications?

Using information found on this site and across the web, I have discovered how to transform most of the binary data in a ._ file to readable text.

However, most of the files that I have examined look like this:

Mac OS X       "
        @
ATTR
This resource fork intentionally left blank

After reading another Ask Different question and the Matt Deatherage explanation that Graham Perrin linked to in his answer, I am still quite confused. Especially considering that Matt said this:

Note that "._MyFile" is not "a resource fork", and not "metadata", but could contain either or both of these. It contains anything that the Mac OS X file system supports but the volume's own format does not. You rarely see "._" files on HFS Plus because HFS Plus supports all the metadata that Apple has defined, now or in the past. You see a lot of them on UFS, FAT16, or other old formats that don't support rich metadata because the OS has to put this stuff someplace.

...

IF YOU DELETE ._MyFile OR SIMILAR COMPANION FILES, YOU ERASE ACTUAL FILE SYSTEM DATA THAT A PROGRAM ON YOUR SYSTEM HAS EXPLICITLY SET.

...

If you want to move the disk back to your Macintosh and have the files all work properly, I strongly recommend that you leave companion files alone. Deleting companion files is corrupting the file.

Wow...sounds like those files are pretty damn important according to Matt! Yet upon inspection, I have tons of them (mostly videos that I've played once on this Mac through VLC) that say nothing more than "this resource fork intentionally left blank".

So why the heck are these being created?! Am I missing something that is important by running xxd -p /Volumes/Videos/._<Name of movie file> | sed 's/00//g' | tr -d '\n' | sed 's/\([0-9A-F]\{2\}\)/0x\1 /g' | xxd -r -p | strings | sed 's/ptb[LN]ustr//g' on the offending files?

In my experience, these days it's pretty rare for there's files to contain anything of much importance, though it is possible a piece of software might choose to do so.

Historically it wasn't too uncommon for a file to have both a data and a resource fork, application binaries especially did this. I can't think of any modern software that uses a resource fork anymore though, so it's unlikely this is why you are seeing these files. Most of the API's are long deprecated, and Apple doesn't recommend using it to store arbitrary data.

You can check for such content on a file using cat filename/..namedfork/rsrc | xxd (on the main file, not the ._ file), though it might be necessary to move it to an HFS or APFS file system first, not sure. The xattr CLI tool should show it too.

The main thing these files are used for currently is storing extended attributes (which have some size limitations). Things like Gatekeeper quarantine info, last line and column edited in a text editor, or resume time in a video player.

You can inspect this information using the xattr CLI tool, though it might be necessary to move it to an HFS or APFS file system first, not sure.