Apologies in advance, as this probably going to be a much bigger theory dump than you may have imagined getting as a response. 
Icons are—at least in the level of design intent of the software—meant to be a way of indicating the high level (and often unique) type of a thing, rather than a status of a thing, such as the Label, or even other custom metadata might. As such, they were never given much by way of power in the software. The idea behind them was to make skimming the binder easier, to give it a little more “shape” and colour than just a bunch of white rectangles and the occasional blue folder… and that’s about it.
Years later, a concrete concept of type was added to the software, though it is for the most part not visual: the Section Type. If you are unfamiliar with them, or have only ever used them as a necessity when compiling, the full reference on their usage can be found in §7.6, Section Types, of the user manual PDF. Toward the very end of that section is something that could be of benefit to you, and that is to combine the custom icon, the section type and the notion of document templates. Then instead of having to go into multiple menus and panels every time you create a distinct thing that deserves having its own type, you can do it in one shot from the Project ▸ New from Template ▸ submenu.
So what do Section Types conceptually give you? They give you exactly what the icon “pretends” to: a true concept of designation, of classification, that can be searched for, sorted by—they are true metadata, and just like all metadata in Scrivener, they can be very powerful tools. I’ve written a bit on why Section Types should be considered as a writing tool, not merely something one must by rote, solely for the purpose of compiling (also note the follow-up post which goes into even more detail on the concepts; it’s an interesting thread to read, even if a tangent to where you’re at with this request).
Let’s say you’re coming at this from another angle though, rather than thinking of icons as a way of denoting type, and more of status. There was a recent discussion on that in fact that you might find interesting (although it does inevitably cover much of the same ground as the above). Another thread is how to make a custom metadata field that holds an icon.
As for where we should go with Scrivener’s design in the future, I’m not entirely sure. There is certainly something to be said for looking at how a thing ends up being commonly used. You can add a thing with a very specific purpose in mind and then find very few people use it that way, and in some cases it’s best to put your foot down, in a manner of speaking, and reinforce the original design intent in future evolution, but sometimes it’s good to step back and maybe see what you’re missing. One thing I can say is that I would hesitate toward seeing Scrivener go down a path where icons become more commonly seen on everything in the draft folder, or even the binder as a whole. For one thing, you give up an awful lot of information by doing that (see Table 7.1, in the user manual).
We have a companion version of Scrivener for iOS that indeed had to abandon expressive icons as it would have been technically very difficult, and I personally find its outline frustrating to use for how opaque it is. One has no idea how much development has been done in areas of the draft outline, whether something has snapshots, etc. Everything just looks like a “page”, even if it is completely empty or nothing but an index card.
For stand-out things though, that have a very special purpose in the draft as an element, I do often use icons in conjunction with section types, and document templates to set them both at once upon creation. Sometimes that information is more important than whether I’ve started writing in the section yet or not.
But it is definitely something to think about. Icons in general are quite useful in their very narrow role, but quite useless for other things, and that we often see people trying to make them useful despite that is something to take note of.