The developers on my team (and the testers as well) generally do exactly this (pull the value we are checking from the config to ensure that the feature works as designed). We also have a suite of configuration unit tests to verify that the values are set as expected for key values. We've enjoyed the benefits you mention in the majority of our tests, while limiting hard-coded configuration checks to a small set of very fast tests. For system integration / acceptance tests we grab the configuration from the product, to avoid duplicate configuration in our test configs.
The largest benefit is a separation of concerns. A good test should test one thing only. One test verifies that the feature works (the timeout happens when the config says it should); another test verifies that the value is correct. Hard-coding the value is testing two things at once.
While there is a risk of getting the values wrong twice, hard-coding the values in multiple tests doesn't really help with this (the test-writer is likely using copy-paste if they get it wrong twice, and will continue doing so if doing it more than twice) and does increase the maintenance costs of the test suite significantly, which discourages thorough testing.
Some of the configuration tests can look a bit silly; it's almost redundant to just look up a configuration value and check that it equals a hard-coded value. However, they do work and have saved us from bad config changes; and more elegant tests can also verify logic and configuration consistency (e.g., ensuring that no production environment URLs are in any non-prod configurations).
ETA: Testing configuration permutations does not generally make a ton of sense for our particular project. On projects where it did matter, I still took this approach and use the product configurations in the tests (increases code reuse with non-configuration tests). However, I also added asserts to verify the values under test are what the test expected, and those asserts had values or logic about the values hard-coded / stored in test configuration. I really don't see why you would hard-code something you could pull from a config unless the correctness of the value itself was currently under test.