A bit of a more pragmatic answer, focusing on why and not on what is and isn't source code. Note that generating source code is a part of the build process in all of this cases - so the generated files shouldn't find their way into source control.

Interoprability/simplicity

Take Google's Protocol Buffers, a prime example: you write a single high level protocol description which can be then used to generate the implementation in multiple languages - often different parts of the system are written in different languages.

Implementation/technical reasons

Take TypeScript - browsers can't interpret it so the the build process uses a transpiler (code to code translator) to generate JavaScript. In fact many new or esoteric compiled languages start with transpiling to C before they get a proper compiler.

Ease of use

For embedded projects (think IoT) written in C and using only a single binary (RTOS or no OS) it is quite easy to generate a C array with the data to be compiled as if normal source code, as oposed to linking them in directly as resources.

Edit

Expanding on protobuf: code generation allows the generated objects to be first-class classes in any language. In a compiled language a generic parser would by necessity return a key-value structure - which means you nead a lot boilerplate code, you miss out on some compile-time checks (on keys and types of values in particular), get worse performance and no code completion. Imagine all those void* in C or that huge std::variant in C++ (if you have C++17), some languages may have no such feature at all.