Worth is subjective
"Is it worth it" is generally not objectively answerable when talking about realistic testing expectations.
Generally speaking, we don't get as much time to write tests as we would like to have. If time were infinite, we'd write every possible test scenario we could think of.
But time is not infinite, so we make judgments based on time/effort taken to write and maintain certain tests, and how much value they add (i.e. by preventing uncaught bugs or regressions).
This judgment is very subjective. If you're creating a blog site, who cares if it happens to go down because of some remote bug? The cost of failure is so low that there's little reason to write very detailed test scenarios.
However, if you're writing the driver for a medical device, or you're writing the core logic for a space rocket; the cost of failure is significantly higher. This means that there's more of an incentive to deeply test your work.
Testing hardcoded values
Tests should focus on behavior, not implementation. Whether a value is hardcoded or not is an implementation detail. On principle, you should not be making a decision on whether to write a test based on a particular value being hardcoded or not.
However, that's only part of the consideration. For example, let's say that this value is a key to an external API (and let's ignore that we should make this configurable for now).
There's still no value in a test that asserts that this hardcoded value has changed. However, there is value in a tests that asserts that you can connect and interact with that external API.
It might sound like I basically said the same thing twice, but context matters here. Being able to interact with an API is part of the application's behavior, which is what your tests should focus on. Whether or not this relies on a hardcoded value is an irrelevant consideration. Whether it does or doesn't, you still need to interact with that API.
Let's say that the external API changes tomorrow and no longer needs a key to work (e.g. because they've whitelisted your IP address). A test that confirms if the key value has changed would become redundant. A test that confirms that your application can interact with the external API would remain to be relevant.
This is why we test behavior, not implementation; because the implementation might change and evolve over time and it would be unproductive if this forced us to revisit our test suite.