A simple way to understand padding is to look at an example file in a hex editor.
I removed all padding from this file, which is why straight after the last tag, the actual audio part begins.
NO PADDING:
If you were to add to the tags of this file, it would have to be rewritten because there is no space for new tags to be written to.
That's where padding comes in.
128 BYTES PADDING:
This is the same file with a padding of 128 bytes as you can see by the 00 00 area.
If you now add tags to this file that do not exceed 128 bytes, instead of rewriting the entire file, only the tag area (including the 00 00) will be edited to accomodate the new/changed tags.
Since that is far faster than rewriting the entire file, having padding is usually recommended even tho it technically "wastes" a bit of space. I find 4096 bytes or 4KB to be a good value as it allows for adding quite a bit of text while wasting very little space (and 4KB is the usual block size, at least for NTFS).
Another way that huge amounts of padding can end up in a file is if you embed images and then delete them from the file. The padding of flac files is not automatically shrunk back down.
If you add a 2.5MB cover file to a 12 track album and then remove the embedded image, each track will still have 2.5MB of padding, wasting 30MB for nothing.
Optimize FLAC will rewrite such files and set a sensible padding of 4KB.
I've personally solved the padding issue in my workflow by writing my own flac recompression script flacr to recompress flac files with the newest encoder while verifying their integrity, setting a fixed padding of 4KB and also calculating and writing Replaygain tags in one fell swoop. Feel free to check it out.