The *point* is there is a cost to walking such structures. Ideally, one wants constant time operations. Barring that, something like log N. If you have to walk a structure to *find* an entry, then this is at best linear time -- not counting the cost of the resources allocated and thereafter wasted.
For a news reader, you barely need *megabytes*. If you have opted to put gigabytes into a product, you likely *need* gigabytes (else you could reduce the product's cost by provisioning it with less resources)
If you don't have backing store, then running out of memory is a panic().
The operating system's role is to manage resources. How efficiently it can do that depends on the set(s) of applications running on it.
And, you reboot the processor and life goes on.
Most applications aren't "desktop" applications. The consequences of exhausting a resource can be significant -- up to and including loss of life.
Unless you can KNOW, a priori, what all of the allocation/release patterns are and GUARANTEE you won't run out of resources, you can't use a dubious algorithm in a situation where the consequences are more than "inconveniencing a user with a spurious reboot".
Simple only works for simple problems with dubious performance requirements. When you have to meet performance goals, you can't "fudge" your approach to a problem.
Imagine every filename on your disk being present in ONE long list so you had to walk that entire list to find the file you sought. Imagine how dreary the performance would be for ~500,000 files (most windows machines have comparable numbers of files).
So, you don't pick naive implementations just because they are "simpler".
Newsreaders are boring applications. No one sits and worries about how long it takes for an article to appear.
But, a DaVinci robot
Being able to tailor an implementation to the needs of an application lets you match provisioning with requirements -- so you don't "pay" for resources you don't (or rarely) need... or, run out of resources unexpectedly. If an application wants a dictionary created that it will access using "small integers", you would create that (on demand) differently than one that wants to access thousands of entities using strings as keys (e.g., like in a filesystem).
Being able to create *both* types of dictionaries in the same deployed product is a win as neither has to be compromised by "settling" for an implementation that favors the other.