If we switch to root in the task output then the output of --show config will show root.foo.bar = x instead of config.foo.bar = x for every config item. This output appears among many other messages unrelated to the config, making the data hard enough to spot already. I think it will be much, much harder to spot and more confusing if the word config changes to root.
I disagree with Jim (which is a bad sign, since he's usually right) when he says it should be obvious in context that a .py file is a config override file. I have not found that to be true. I admit that many config override files are in a directory named "config", but that's just for obs-package-specific override files, not files in test directories or private directories where a user is messing about. And even if it were always true, a user may not know where a file is located when trying to understand that file.
It is even worse for the "--show config" option when running a task. There is no context in that situation. The user sees a lot more output when using that flag, but which are the lines the user is looking for? Why should the user expect them to start with root? Wouldn't "config" be easier to spot? I certainly felt so, which was why I took the bold and possibly obnoxious stance of forcing "config" even when config files used "root" instead.
I understand the argument for "the root of the config", but we're calling it "root" not "configRoot", so the result is a conceptual purity that I feel obscures the underlying reality that we are setting an attribute of an instance of a Config. I think we all agree that configRoot is too wordy, so we must abbreviate it, thus losing information. The two obvious abbreviations are "config" and "root" and I feel the former is much clearer. If we use "config" everywhere then the user sees "config" and should mentally add "root" to get "the root of the configuration". As it stands, the user sees "root", but where is the clue that tells them this is a configuration object?