It may be helpful to think of a theorem not just as an expression of mathematical truth, but also as a tool that one mathematician or group of mathematicians have developed for use by others. It is like an API in a software library, that other authors/programmers can invoke when they have a need for it, without having to understand the low-level details of how the API does what it advertises itself as doing.

To continue this analogy, a well-designed API will often offer ways of doing things at several levels of generality, one that can be used in simple/common cases, and another (or several other ones) that’s used more rarely and supplies more arguments/parameters, more customizability options, handles difficult edge cases better, etc. The more advanced API call does everything that the simple one does and more. But learning how to use it involves more effort on the part of the programmer, so in practice most programmers will rely on the simpler method (often labeled a “convenience method/function”).

The same goes for theorems. Mathematicians sometimes need to “invoke” Euclid’s theorem on the infinitude of primes as part of a proof. Should we force all of them to learn about a much stronger fact, the prime number theorem, or one of the even stronger results that have been proved about the distribution of prime numbers? No, it’s much more convenient to keep Euclid’s theorem around as a “convenience method”. Even in your functional analysis example, I’m pretty sure the first theorem about $\mathbb{R}^n$ is useful (in the sense of being invoked as part of an argument) often enough to justify “having” it, even though in a formal sense it is superseded by the second one.