To a preprocessor, the extension of a file really doesn't matter. You could put code into a file with a "JPG" extension and you could still #include it without error provided that the code is legit.

One of the reasons why, conventionally, it's considered bad practice to #include files with a source file extension is from a basic build/make perspective. Imagine you are porting a large-scale project to a new, cross-platform build system (say, 50 million lines of code).

You now have to specify which files are to be built as separate compilation units (object files) to be compiled separately and linked to form the resulting binary. If your codebase has a habit of using the preprocessor to include files with a source file extension, then you have no idea just looking at the file extensions which files are to be build as separate compilation units and which files are actually just meant to be included by the preprocessor. So then you might face a spam of errors just trying to build all the source files as separate compilation units as a sane person would, and may have to debug your build process using a fine-tooth comb while inspecting all your code and trying to figure out which file is meant for what.

At a higher level, beyond file extensions, if you actually define things in source files and include them with the preprocessor, then you risk redundant linker definitions of the same symbols, tricky link-time (and possibly compile-time) errors. Moreover, this can exhibit a general breakdown in thinking between the separation of interface/declaration (headers) and implementation/definition (sources).

There are exceptions like unity builds which do this as a build-time optimization and may be somewhat acceptable with careful coding standards and with real, measured benefits to the practice, but in general, including source files can be really confusing and a sign that the developer doesn't really understand the point of separating declarations from definitions or the confusion this can cause when trying to establish a build system.

Why is it not good practice to include source files into other source files?

Source files contain definitions. These can cause multiple definition errors and thus generally should not be included in other source files. Even if you avoid multiple definition error by compiling only the files which includes other source file, code can become unmanageable.

In header files, you just introduce some symbols to compiler and inform their types. This allows you to separate the interface with the implementation.

For example:

file a.c

int a = 42;
...

file b.c

/* Example of bad code */
#include "a.c"
...

When you compile a.c and b.c and link them you will get multiple definition linker error.

If one plans to include multiple source files into just one file and compile that one file, it will introduce a lot of pollution (macros, static functions etc) which is something not very manageable for readers and for the compilers.

^{p.s. When I say generally, I mean sometimes including source code may be useful. But in such cases to avoid the confusions to readers, I would prefer to rename the file suffix to some thing other than .c, may be .inc or similar.}

As mentioned before, the main argument against including C files into C files, is the high risk of multiple definition errors. And since it is a very seldom used technique, it causes unexpected side effects for code maintainers.

Of course, in very special cases, including a C-File might be the lesser of two evils. For example, if you want to write unit tests for static c functions, you might include the C file into the file with the unit test.

see also: How to test a static function

Another unusual but valid use is separating class or function templates from their definition (C++): https://isocpp.org/wiki/faq/templates#separate-template-fn-defn-from-decl