If a client closes its JMS session (intentionally or not) and then invokes javax.jms.TemporaryQueue.delete() or javax.jms.TemporaryTopic.delete() these methods will return without actually deleting the destination (because the underlying session was closed). This can be confusing and/or mask programming errors.
The JavaDoc for javax.jms.TemporaryQueue states that a JMSException should be thrown, "if the JMS provider fails to delete the temporary queue due to some internal error."

This may lead to a leak of temporary destination caused by programming errors. For example if someone was using

try (QueueSession session = queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE)) {
      replyQueue = session.createTemporaryQueue();

     . . .
      
} catch (JMSException e) {

      throw new RuntimeException("Failed to send and receive messages", e);

} finally {

      replyQueue.delete();

}

the replyQueue would never be deleted since when finally block is executed the session is already closed. This is obviously a programming error but masked by lack of any error feedback from the delete() method