It is very common to have the same code base used for a family of products.

Some models are premium editions with extra hardware capabilities, while some are lite editions with only the bare minimum.

Conditional compilation/assembly then allows you to build the same source multiple times.
One time to produce a big binary with lots of menu options, but only working with a product with much hardware.
One time to produce a small binary with fewer menu options, but (probably) working on all hardware. But intended for the lite hardware that doesn't have a temp sensor, ...

Also, you may have the same product but produce with one processor for the first 2 years. Then you need to switch to a different processor because of support (or capability) issues. So you select conditionaly if building for the old or new processor. Might be a different UART initialization in the newer processor.

Another thing is that you may want to conditionally turn off some of the product features, to release code/RAM space for conditional addition of special debug test code. So when testing GPS functionality, you turn off temperature sensor processing but adds extra debug output for the GPS. When testing temperature sensors, you remove support for the GPS but instead stores lots of temperature samples allowing you to emit noise and response-time information from the temp sensor.

Compile/assembly time conditionals are very very useful. Note that in most situations, it's possible to skip these features and instead use a standard C preprocessor and feed the already preprocessed files to the assembler. The advantage with that is that you can make use of a common C header file to control both assembler and C/C++.

But a compiler/assembler that does not come with any built-in support for conditional processing is really a quite poor and lite product.