I think the focus of the article is in highlighting the allocation performance (which is the goal of the StringPool) vs. overall performance (i.e. speed) and so the benchmark, while being artificial, is designed to focus on that specific thing. This is actually pointed out in the article just before showing the benchmark results:

It is important to note that since the focus of StringPool is reducing memory allocation, our main focus in the benchmark is on allocations more than on speed:

I agree that an additional benchmark, showing it in a more real-world scenario could prove helpful, but the existing benchmark does a good job of highlighting the allocation reduction seen when processing large numbers of char data. A more real world example would be something like a file upload validation method which is first checking the file extension against a HashSet<string> of valid extensions. In that scenario we would be able to take the filename as a Span and extract the extension from it as a Span, but we cannot call HashSet.Contains() with a Span, we have to use a string. So that would require calling extensionSpan.ToString(). In this scenario, we could use the StringPool to avoid unnecessary string allocation (while the article does not use this particular example, it does mention other related scenarios).

Overall, as you mention, the real use-cases for string caches (such as StringPool) are pretty rare, it is a niche topic, but for those who need to do something like that, I think the article helps to present an accessible introduction.