Thank you all for your feedback! I didn't expect such heated discussion for such a tiny feature, but apparently I should have put more thought into this before releasing. Thankfully, we're still in beta stage.
I'm very hesitant to add yet another configuration option. I know it's great to be able to configure the exact size of the padding, but it will result in just more configuration options — there are also other tag formats with padding 
The discussion above revealed an inconsistency wrt. the new optimization feature: while writing tags, Mp3tag adds 4KB of padding in case the file needs to be rewritten. This should also be — and it's what most feedback here shows — the default when optimizing the padding. So I've just released Mp3tag v3.23e, which does exactly that: if you choose Utils → Optimize FLAC from the right-click context menu of FLAC files, the files will have 4096 bytes of padding after optimization.
I want to address this quickly: removing padding from FLAC after, e.g., removing embedded cover art would require rewriting the file if a new cover is added. I've tried to not be smart about this, because there are many different workflows, which might be disturbed by such automatic behavior. I think you meant your comment not as a suggestion, but wanted to quickly explain for people who are wondering about that.
And maybe there is also a silent group which was very happy with the complete removal of the padding. Please raise your voice so that I know, but also please use the workaround via metaflac for the time being.