Current FAT32 implementations handle 4GB files just fine (FAT16 can't support a volume big enough for that size file unless you use large sectors, FAT12 can't support that big a volume period). I could certainly believe that some older ones squawked, or that you might find an unusual one with an issue. Applications are also vulnerable to bugs at that point (and I'm certain we could find plenty that had problems at that point), but that's a bit of a different issue.
I remember when file sizes first started bumping past 2GB on mainframes - we definitely ran into problem both in the file systems (especially VSAM), and in applications (although since these tended to all be structured files, it was more often the file system with issues, since the application typically didn't use that offset directly).
NTFS (along with many other file systems) support files far in excess of 4GB. All the native Win32 file APIs use 64 bit values for offsets (even on FAT =96 you just can=92t create a file big enough to use the high word there), although in some cases there have been a couple iterations of those - the original using a pair of 32 bit values, and a more recent one using a 64 bit value). Again, I'm sure there are applications with issues at both 2GB and 4GB.
The 4GB file size limitation on FAT is a problem for many applications, like media ones, which can produce quite large files, and some actually go to the trouble of segmenting files so that your video source ends up as multiple 4GB files on your 100+GB volume. Or just insist on NTFS...
And we are talking volume sizes, not file sizes.