Polls exist in Discourse, yes. The primary issues I saw discussed internally were more technical (e.g. “what can we do that will have good performance and make sense given the current architecture”) than design, so not really appropriate for a poll. In any case it would be up to the dev team if they want to solicit that level of feedback. Sometimes they do.
More generally I am strongly in favor of people like yourself - with an interest in the specifics of how a feature might get implemented - creating or participating in forward-looking discussions that can help inform future development when the time comes. I take this approach myself, and some examples that might help illustrate what I mean would be:
or
Perhaps you see that not everyone likes to take this speculative approach by the fairly low participation in both topics. 
There is, of course, already the existing Tree Nav discussion topic, where you can add your thoughts on what you’d like to see, and it can help inform the dev team’s process:
I see that you are, but I don’t know why. I’m not sure I need to know why, I’m just saying that your conviction about it is not, in itself, convincing. 
Yes, it is indeed “too democratic”, because what matters here is what is the most effective way of gathering user opinion and measuring the relative strength of their desire for particular features and changes. And then how effectively and efficiently the dev team is able to take in, interpret, and incorporate this data into their own decision making process. So ultimately it is something the dev team needs to decide, weighing their own needs and internal processes, etc. against the available options for getting feedback and how useful the feedback generated in that way is to the dev team.
Also keep in mind that user sentiment is just one factor used in determining when and how something will be developed - it is an important one, but one among several, some of which (such as architectural limitations) are more “immovable objects” than user desire. 
The problem with this idea (and of course we also thought of it) is that people were under the impression that hearts/likes were “votes” for quite some time (as we in fact told them) in the old forum. So they acted as if that were the case, casting many votes, and the current like counts reflect that. We gathered a lot of potentially useful data this way. If we now change the rules and essentially throw out all previous “votes” by converting them to just “likes”, we lose a year or so of potentially useful measuring of user sentiment on ideas.
Not only that but people are unlikely to go back and re-vote on things, so there will be a strong recency bias in what is voted on. There are literally hundreds of feature requests made to-date, nobody will go back through them all, most will not go back at all, or maybe will go vote on a few favorite features they think of, and this somewhat defeats the whole idea of the limits and their benefits anyway. It biases the feedback, which is definitely something we don’t want.
So I think we’d have to find a way to either convert likes to votes, or to keep the likes and votes but to also measure the likes in some way. In other words the Likes would have to still contribute to any measure of user sentiment on a feature request, even if Likes count for more. That was, in fact, my idea, which was that a “like” would count for 1 “point” in internal feedback weights, and a “vote” could count for more, perhaps 3 or 5 “points”. Then it would make sense that votes were limited and likes were not, and that both votes and likes existed, because they reflect different levels of support. That said, it was agreed at that time that having both would be too confusing, so we have not taken that approach yet. I still think it might be workable, but there is concern about it in the team, and I understand that. If you’d like to put in your support for the idea, I welcome it.
Of course. But you can at least reasonably say that the path taken by these companies (for gathering feedback) has not evidently harmed their intake of feedback management and acting based on it to the point that they are so out of touch with users that their product adoption suffers significantly. Obviously that is a large effect to judge, and the effects of varying voting behavior and rules may be smaller, but then… that’s part of the point. We are arguing about how best to handle votes, and the real question should be: how much does it matter? To what degree will it affect the outcome? If it is small, a difference of 10-20% of “accuracy”, then it is frankly not worth debating endlessly.
Perhaps more compellingly, the way that many entire feedback management systems like Canny work, by default, is to not limit votes. It is, in fact, a very old feature request in Canny’s own feature vote board (back to 2017), but ironically without much support, relatively speaking. Anyway, you’d think that a company whose entire business is essentially taking in and measuring user feedback would have thought about this and implemented it if it was really important. UserVoice does have vote limits, but they are not at all universally applied by customers. Ultimately I am not saying one is clearly superior to the other, in fact I am saying precisely the opposite: there is no clear consensus among experts in the area we are discussing.
This is… an interesting straw man. 
Innovation in software design and development is not equivalent to innovation in the process of doing software design and development. One can innovate in the product one creates, but not take some incredibly innovative approach to the actual work. Indeed this is often what is done.
And in any case framing limited votes as if it is some innovative approach to accurately reflecting user sentiment makes little sense. It is first of all a well-known and reasonably widely used approach (though not, by any means, a dominant one), and second and perhaps more importantly in this case, it is how the Discourse voting plugin already works, by default.
I see this now. I’m afraid I can’t spend any more time digging into this at this level of depth, however. For one thing, it’s a time sink, but perhaps as important or more so, I am merely explaining from my perspective what is going on, but these things are not my decision to make. I am trying to help you (and ideally others) understand why some decisions are made, but I am not the person you really need to convince. 