Summary:
The "thumb size" option severely degrades performance for users who have it enabled and consumes cache capacity for little benefit. The feature itself is probably redundant to capabilities built into modern browsers. It is probably best to simply remove the option.
Context:
The "thumb size" option allows users to choose how big they see images in articles. It was presumably intended to allow users to customize page display to accommodate their screen size and available bandwidth.
We currently support eight different values between 120 and 400 pixel. The thumbnail size is applied Linker class used by the wikitext parser, appropriately scaled thumbnails are generated on upload (or on the fly if missing).
Problems:
Usually, the HTML generated by the wikitext parser is cached for later re-use. This is done because parsing is relatively slow - depending on the size and complexity of the page, it can take several seconds. However, when the "thumb size" option is used, this caching becomes ineffective: since there are a relatively large number of possible options, and relatively few people use them, the chances for a "cache miss" are high (cache fragmentation).
In effect, users that have "thumb size" set to a non-standard value are much more likely to hit an uncached page, forcing them to wait until the page has been rendered for them.
Generating image thumbnails in many different sized also clutters the on-disk cache on the media servers with scaled copies of images that are rarely used. This is particularly true because copies scaled to all possible thumbnail sizes is generated for all images, even if they are never used in an article (compare T106640).
Finally, the benefit of the option seems redundant. It is probably be better to rely on responsive image loading mechanisms available in modern browsers via the srcset attribute. MediaWiki already supports this, see https://www.mediawiki.org/wiki/Manual:$wgResponsiveImages.
Usage:
An ad-hoc analysis among users of en.wikipedia.org who have edited in the last 30 days shows that about 4% of active editors have the "thumb size" option set.
Solution:
If there is no great demand for this feature, we should simply remove it. If the feature is to be kept or replaced with a mechanism for adjusting the thumbnail size dynamically, it should be re-implemented in a way that prevents it from fragmenting the parser cache. This could be done by injecting the appropriate size parameter into the rendered output, using a mechanism similar to the one that we use for section edit links (this is currently done by the ParserOutput class).