I've put some more thought into this and have discussed it with another core developer.  While the idea was inspired, I think we should decline the API expansion.

When I last talked with Guido about this module, he opined that he didn't want to module to get further into the business of moderating between the producer and consumer, that it should focus on its core task of being a one-way thread-safe message queue.  

I agree that users do craft various ways of communicating via sentinel objects; however, there is no one pattern that dominates so much that it warrants deforming the API to accommodate.  FWIW, I use email as the basis for my mental model of how Queue is used.  With email, we don't don't need a special part of the API to communicate that we're not going to send messages any more; instead, we either stop sending messages or send a farewell message.

Of the two ideas, making queues iterable is more plausible.  However, it doesn't fit will common ways of using a queue.  For non-blocking queues it makes zero sense.  For daemon threads that block until sent a message, the usual pattern is while True loop that blocks on a get().  In such a case, a for-loop might be more compact but doesn't reflect how we think about the problem (implying that the loop may terminate and it  obscures that the get() is what is actually blocking).

Sorry for taking a while to evaluate this.  I looked at the effort you put in to the patch and wanted to really think it through.  This idea is inspired, but in the end I don't think it is a good fit for how people typically use the Queue module (or its cousin in the Multiprocessing module).

Do consider posting a queue variant to the Python Package Index.  Though not for all users, there may well be some uptake for a few users.