I will tell you the most important difference between v3 and v4. V3 has a bug which is fixed in v4, but the fix may break older software.
ID3 tags are meant to go in front of mp3 files. Mp3 files are arranged in frames. Each frame begins with "synch bits" which tell mp3 players where each frame begins. The synch bits are 11 or 12 consecutive 1s. They do not need to start on a word or byte boundary, they can be anywhere in the file stream. The designers of ID3 knew that they could prepend anything to an mp3, as long as it didn't have the synch bits. So, for numbers, they designed a "synch-safe" scheme. Simply, bit 8 of every byte holding a numeric value is set to 0, and the other bits shifted to the left. Here's an illustration of how that works:
0xxx xxxx 0xxx xxxx
<-dcb a987<-654 3210
The problem was that in v3 they didn't specify that frame lengths were sync-safe. This leads to the possibility that a frame length could contain 11 consecutive 1s. If the length were 2047, for example, an mp3 player would interpret that as a mp3 frame, and, presumably, a very ugly sound would come out. There are other numbers which could cause this problem: 4094, 8188, 16376, etc. Now, the likelihood of this happening is low. Obviously, the odds against this happening are enormous, and I know of no examples of it actually occurring. Still, they fixed it v4. The v4 specs say that frame lengths are synch-safe.
And that's the problem. If an older metadata reader which doesn't know about v4 changing the frame lengths to synch-safe reads the synch-safe number as a plain number, it's going to come up with the wrong length if the value is greater than 127. This is a distinct possibility. So we're waiting for all older software to be updated to be v4-aware. It's actually been 22 years. It's probably safe now. OTOH, things are working fine, and there aren't really that many improvements in v4. I like the TMOO frame, mood, and TMCL, the musician's credit list, but they aren't enough to warrant the whole thing breaking.