People like file extensions whether or not they're necessary
In some circles, it's popular to denigrate file extensions as a Windows-ism that's only necessary because of (historical) limitations of that platform. However, we have a fair amount of evidence that people like file extensions even on platforms where they aren't necessary, and adopt them by choice in various circumstances even without technical need.
The obvious primary source for this evidence is people's habits on Unix. Unix doesn't need file extensions and they're by no means universally used in file names, yet they are popular in a variety of situations. The most obvious example is that Unix based programming languages very frequently have a convention of using specific file extensions on their source files. For modern programming languages you can say that this is some degree of wanting to go along with the convention and wanting to be cross-platform to Windows, but it's harder to make this view stick for older languages that predate assumptions that everything would wind up on Windows sooner or later.
(It's not just programming languages on Unix that use file extensions. For example, it's entirely a convention to put tar archives in files with a .tar extension, but it's pretty universal.)
The situation with C is especially striking, because C uses two file extensions, .c and .h, despite there being no technical requirement for this within the language. You can #include a file with a .c extension just as readily as you can a .h file (and sometimes people do), but purely by convention we use the two extensions to signal the generally intended use of the file (and then the C compiler frontends go along with this by looking at you funny if you tell them to compile a .h file). People clearly like being able to see a clear split of intended use.
Compilers for C and other languages show one use of using file extensions, namely that they let you create a bunch of different file names from a base name plus a varying extension. Starting with fred.c you can traditionally ask the C compiler to generate an assembler version, which winds up in 'fred.s', or turn it into an object file, 'fred.o'. Sometimes you'll go straight to a final executable, conventionally called just 'fred' (with no extension). And you can have 'fred.h', the visible API for the code in 'fred.c', and most everyone will understand what you mean just from seeing the two files together in a directory listing.
One potential reason for the original popularity of file extensions
on Unix is that Unix shells and other Unix tools such as '
makes it convenient to work with file extensions if you want to do
something to 'all C files' or 'all C headers' or the like. Another
is that putting this information about the intended file type into
the file name makes it immediately visible in directory listings
and other places you see file names (which may include other files,
for example Makefiles).
You can argue that all of these things should be done through file 'type' metadata (which would still let you distinguish C headers from C source code). However, the drawback of this is that people would have to learn additional sets of syntax and features for searching and operating on this file type metadata, and some things would be more awkward that they are today (where you can ask for file name patterns like 'vdev*.h').
Sidebar: The original Macintosh and its lack of file extensions
The original Macintosh operating system (ie, classic Mac OS) explicitly stored both the 'file type' and creator code of every file separately from its name (see the Wikipedia entry on resource forks). As a result, I believe that people mostly didn't use file extensions in classic Mac OS file names. I suspect that C programmers on Mac OS may still have called things 'file.c', but that was probably partly through custom and habit.
(I once did write some C code on classic Mac OS, but it was so long ago that I've long since forgotten how it worked.)