Maybe some background why there is padding in the first place: In most current formats the tags are located somewhere at the beginning of the file. That makes sense as you have quick access to the tags, no need to seek for the end, and even in cases where you e.g. only partially have downloaded the files you might already be able to read the tags.
The downside is that when you change the tags and their size changes you need to resize the entire file, which might also involve, depending on format, adjusting some offset positions stored in file. Rewriting the entire file usually is much slower then just changing a few bytes of tags.
So to work around this software writing tags usually adds some extra empty space behind the tags as reserve. So when you in a future read add some data and that fits within existing tag size + padding there is no need to rewrite the entire file. You can add some data to the tags and it will just use up the existing padding, and if you remove data it will increase the padding.
Especially when tagging larger files like FLAC you might already have experienced this: After adding a significant amount of tags saving for the first time is slower, saving the same file again with maybe only minor changes is quick.
I don't know about Mp3tag's implementation, but e.g. the Python library mutagen by default will add a padding of 1 KiB + 0.1% of the file size after the tags as default padding. It will also shrink back the padding to that size if it exceeds 10 KiB + 1% of the file size after the tags. For Mp3tag you might find some details here in the forum.
For your library this would mean roughly 0,25 GB of padding.
UPDATE: Not sure if this is still valid, but
That would mean for your 25k files roughly 50 MiB of padding, about 0.02% of your libraries size.