In any case, the thing that we tried to make clear with that paper is that there are different ways to make software do different things (variability) and that these techniques have trade offs. That's still true today and people using the wrong ones make life harder for themselves and their users.
The main trade off is when you have to lock in your choice. With compile or build time feature flags, you are stuck with whatever you set before you ship the binary. You can't change it after. A change will require users to update their software. Configuration gives more flexibility. That breaks into runtime configuration and before runtime configuration.
The broader context here is the notion of companies that build multiple products using the same code base. How do they differentiate products from each other. How do they create new variants. And how do these get configured. Some companies cam up with really complicated ways to do this. The further back you have to go to change a choice (e.g. making source file change vs. setting a checkbox in a configuration screen), the more expensive it gets.
This resonates. Feature Flags over time devolve into a lovely career of code archaeology.
Sit down and let me tell you the tale of "enable_disable_foo_bar_on_web_phone_but_not_model_x_unless_year_is_even"
