Maybe you didn't understand the rhetorical intent of my question. Let me restate.
There are just as many weird problems with websites that cannot currently be fixed in this "pick and choose" manner, because the corrupted state is a single key in the site's localStorage. Instead, the current solution is "blow away the site's localStorage as a whole." (And, in fact, it's usually even less granular than this; you'd usually hit "clear Storage" in the Devtools, blowing away localStorage, AppCache, and a number of other things, all at once.)
Sites' localStorage is thought of as a kind of opaque per-site database—not something to be picked through by users, but rather something that's either in a valid state, or in a corrupt state where it should be purged.
And, as far as I know, that paradigm has been working just fine for everyone! Nobody knows enough about a site they didn't develop themselves to make a change to a single key in a site's localStorage that will take it from a corrupt state to a valid state. The average user—even the average developer—is only likely to corrupt the state further, by making changes roughly at random. We all just "purge localStorage" as one of the "the site is doing weird shit" debugging steps, and never ask for a finer scalpel than that—because that fine scalpel would essentially be akin to picking through the site's memory one raw address-value pair at a time. There'd be no context. It'd be useless, unless-and-until you went through a laborious brute-forcing process.
It's great that you've figured out how to delete particular individual cookies for a site, but you must realize that you learned what worked in each case by brute-force trial and error, in ways that likely corrupted the site's state innumerable times before you created a new valid state. That what you were doing was essentially akin to creating a Game Genie code for the website, poking and prodding at its (opaque!) memory in the hopes that you'll get a useful result, rather than a program crash.
And the argument being put forward in this comments section, is that the mindset required to create a Game Genie code or something like it, automatically implies that the right "home" for said process is the Devtools UX anyway. The Devtools UX gives you the tools needed for iteration and experimentation (a REPL; a live view of the site as you poke at it; etc); while the Settings UX is for knobs and switches where you know what button you want to press from the start, and just need an efficient navigation hierarchy that will let you find it and press it.
By deleting individual cookies within a site's cookie jar, you're debugging that site—poking and prodding at it iteratively—whether you call it that or not. So why expose a secondary, non-iterative interface for doing so? You'd just be encouraging people to do an inherently-iterative process more painfully by using a non-iterative interface.