I think this is an important point: Defining things in a way that supports a program growing.
Sometimes in a new program you know that you have some bit of "configuration". The parameter signature is a super flexible way to handle getting and setting it.
You could start with some-config being from make-parameter. That will tend to do the right thing for most sorts of configuration, even if your program later starts to use multiple threads.
However maybe you have some configuration that should not be thread-specific. Well you can redefine some-config to be a case-lambda, where you use or set! a variable, maybe guarded by a semaphore. All of the call sites (where you set or get) can remain the same.
You could even redefine some-config to be a wrapper around the "raw" thread-cell get/set functions. Or read/write an external data store. Or whatever.
So you could say that parameters are not a bad default to start with, plus that "interface" is easy to update to be backed by other representations.
Having said all that, some people prefer not to have wrapper abstractions like this. As a program grows, sometimes these abstractions help minimize gratuitous changes... but sometimes they hide necessary changes. As with many things, "it depends"?