Note that the kernel and the system.map are both relatively small. Each is less than 20MB, making those all 6 files only about 80MB total
If you run df -h it should show the size of the partition, as well as the used amount. ls -l /boot will show the size of all files in /boot and on my system I see that the initramfs images are much larger, with the rescue image at about 180MB and the image for each kernel may be near the same size (often about 150MB)
Please show us the output of both those commands. df -h & ls -l /boot as preformatted text.
The question is also: Are the System.map files actually required in /boot when they are just copies of the System.map file from /usr/lib/modules/*/System.map?
And not much use in /boot either because /boot can’t be mounted until the root file system is unlocked and mounted. Everything needed to unlock the luks file system must be available in the initrd image.
But the file is expected in /boot by some tools, probably because, historically, Linux make install copies the file in /boot (I have to dig into git history).
From developer perspective, I believe System.map is mostly intended for debugging.
From user perspective, System.map could be optionally provided to depmod when generating modules.dep (used by modprobe to load modules and their dependencies), and depmod expects the file in /boot (and not in compressed form).
So, if the file is not needed for users, may be it can be compressed, and developer tools that use it could be adapted to read a compressed file, or developers be advised to decompress it before usage.
I don’t believe the OP was particularly interested in cleaning space up from /boot.
It was more of a “these files which aren’t really required are just as large as each kernel, and they compress down to a fraction of their original size… why don’t we compress them.”
Clearing space is not the end goal, it was merely the catalyst.