Yeah, in my experience it absolutely can happen, and the way it generally looks is that the dependencies get roughly grouped into larger structs which are then being passed down the call stack mostly as-is, until they hit a certain abstraction level/barrier where the parts of those structs start being passed down.

It's somewhat tedious, that's why modularity becomes even more important: with correctly chosen borders, the grouping of dependencies becomes very clean and self-evident, the whole data flow just flows. Chose them wrong, and you spend most of your time adding and removing those pesky extra arguments.

Yes, when considering software design it's great when you can "smuggle in" a new dependency by adding a new property or method on some already-established payload. I would describe this as "The change requires someone way up the stack to change, but all the intermediate layers require no source changes" which is notably absent from the author's list of "three basic cases that can emerge." I assume the author is well-aware of this technique but considers it equivalent (for the purpose of function coloring) to "The change may require a change to all functions in the stack" since technically the signature of all those intermediate layers did change.

Your configuration structs are not "everything". You probably have dozens of things in them. You have hundreds to thousands of different parameters to different functions. By the time your configuration structs have hundreds of things in them you have thousands to tens of thousands of parameters to functions. Only a fairly small fraction of things make it all the way up to main.

This is exactly what I was talking about with this being a "cognitively available" operation. You notice when you have to propagate something all the way up to the top precisely because it is not something you do very often and it stands out as an exception when you do. If you are literally propagating everything up to main, all the time, every time you change any function anywhere in your program, you are doing something very, very wrong.