I'll mull this one over for a while and take a look at what other languages are doing.   

My first impression is the close() is the wrong word because in other contexts it means that a resource has been freed and that no more calls are allowed.  In this context, the queue is still alive and continued get() calls will work until the queue is empty.

Another first reaction is that this will cause more problems than it solves (feature request to reopen a queue, wanting an API to detect whether a queue is closed, having to learn a new pattern for queue use, adding more complexity to the API, unexpected interactions with join/task_done).

The normal (or at least common) use cases for Queue involve leaving it open indefinitely with daemon threads always lying in wait for more data.  If there were a need to close down a consumer thread, the usual solution is to send a close-down signal/sentinel.  It would be more complicated for the multi-consumer case but that is atypical for Python threads (because the GIL limits getting any benefit).  The multi-consumer case is more likely to arise in an async environment.

These are only first impressions.  I will think about it more.  In the mean time, it would help if you could find a few real-world examples of existing code that would be improved by having a close() method, that would allow me to think more concretely about the subject.

FWIW, I don't normally think of queues as short-lived objects.  It is like having a email account (an atomic message queue) which never close off or shut down.