Great, thank you for looking into this and providing feedback. Any opportunity to simplify things is good. Let's see if we can. This setup was made so that it can allow more features to be added in the future.

Let's go over what you mentioned one by one to see if it makes sense how it is currently specified or we can improve.

• end_time - it is not meant to be the same as the post payout time. Someone creating a poll may decide to have the poll running for 30 days, or one year, or without end. So this field allows for that.
• content_type - we can remove it, sure. But the point is to have a unified standard for all of Hive. Make a post with content_type in the json_metadata, so all frontends know how to recognize that it is not a regular blog post. HafSQL has also added an index for this. content_type can be poll, and in the future we can have job-opening, product and so on. Let's think about how to create standards and processes for all of Hive, to facilitate future growth and ease of development.
• filters - this field gives the ability to add various kinds of filters. The one we have already is a restriction on account age - votes of accounts under the minimum age will not be counted. There are also filters planned for membership in a community and so on. So poll creators can pick any filters they want.
• preferred_interpretation - indeed the name seems too long. The point is to make it clear that this is the interpretation preferred by the poll creator. But it is planned to add to the UI the ability to see other interpretations. For example, the poll creator chose to interpret votes by HP, and to filter out account under 1000 HP, but the UI will allow people to see what the poll results would have been if there was another interpretation and other filters chosen. This can help with decentralized governance decisions. For example, there is interest from the Splinterlands community in using this system for making and voting on proposals.
• There can still be any arbitrary fields in the json_metadata besides the poll fields. So it doesn't restrict from adding anything. But if for some reason it would be better to nest all the poll data under its own field, then we could do that, for example content_type: poll: {}.
• action in the custom_json gives us flexibility for other actions in the future. One planned action is to add new choices to a poll. It is planned to make a poll setting that allows users to add choices to the poll.
• custom_json id could be just poll, sure. It seems more polluted already, whereas polls seems unused. And it seems to better refer to the Open Polls Protocol.

Also would be beneficial if UI sends token data at the time of casting

Which token data - the user's token balance?

Also perhaps instead of poll id, use author/permlink as it is already part of unique post?!

Sure, probably a bit of a matter of taste whether to use trx_id or author/permlink. One consideration is which one would be shorter (so that we keep blockchain bloat to a minimum, as much as possible), and trx_id would seem shorter on average.