Yes, I understand why you designed it this way. But if I understand correctly, the only metric that isn't Sybil vulnerable right now (well at least within a narrow time window like 7 days) is the Shares metric, which depends not only on the user's MVESTS but also their voting power at the time they vote and voting percentage they choose for the vote. A metric based only on MVESTS, although a little harder to calculate than Reward Shares, means that users can vote on each option of the poll with 1% voting weight (like I did for the option above) and have their vote fully counted while wasting the least voting power (actually technically voting weight of 0.01% would be the least allowed amount but the steemit.com UI currently does not allow that level of precision).

Yes, I think the DB approach is the right way to go. I think it would be nice to eventually have iframe embedded polls with nice UI. I'm not sure why you are saying that it wouldn't be secure. The problem with that, however, is that steemit.com and every other client would need to whitelist the domain. Another option that may actually be better could be to come up with a standard for describing various types of polls that Steem clients can adopt. The data, following the standard, that describes the poll could be encoded in JSON and set as a value to some attribute in the div representing the poll that you already ask the user to embed in the post. Then supporting clients (you could start with enabling it on eSteem and then if it gains popularity maybe steemit.com and other interfaces will also adopt it) could read that data and generate the poll UI, while non-supporting clients would just ignore the div as steemit.com currently does. Even in non-supporting clients, users could always still vote manually on the comments as I did, or alternatively use your external website (in fact you could put a link to the external website hosting the poll within the div, and for supporting clients they would simply render the poll UI rather than rendering the contents inside the div). It would be important to define an appropriate and well documented standard for the polls and add versioning support so it can be upgraded over time without breaking clients that have not been updated to support the new version by having them think they can render the UI of a poll using new version features when they really cannot and should not.

Personally, I am not a fan of the added complexity of a token. Perhaps if/when Community Tokens (CT) are supported on the Steem blockchain it will make sense to integrate support with those for the polls (for example polls weighted based on the amounts of a particular CT the voting accounts hold), but prior to that I am not sure it would add any value to add tokens into mix in terms of helping adoption or ease-of-use.