The patch doesn't change the threading module, so I'm not sure if
there's anything in particular you think is performance critical there.
 The places where it uses try/finally are:

  * _Condition.wait.  This performs operations on a mutex which are much
slower than any overhead "with" might bring.  It also has sleep calls in
it to implement timeout support, so it's not going to be extremely fast
in those cases anyway.  I notice, however, that it executes a number of
lines of code outside before setting up the try/finally statement,
allowing for the possibility of a buggy deadlock should an exception
(such as KeyboardInterrupt) occur before the try block begins.
  * _Event.set, which uses _Condition and so also deals with mutexes.
  * _Event.clear and _Event.wait, similarly.
  * Thread.__bootstrap, which writes to stderr and uses mutexes, so is
already quite slow. (but this case probably isn't a candidate for
conversion to with anyway)
  * Thread.__delete and Thread.join,  - more mutexes and conditions.

So there doesn't seem to be anything particularly performance critical
here.  You can argue that the slightly increased overhead of with would
still be bad, even for things that are already slow (such as mutex
manipulation), I suppose.  In this case, measuring the difference would
be a useful step to take.

However, there's also the issue of correctness.  A KeyboardInterrupt can
arrive between any of these mutxes being acquired and the try/finally
being set up.  It can also arrive after the finally begins executing and
before the mutex is actually released.  In either case, this will result
in a lock being held when it shouldn't be, which will probably lead to a
deadlock.  Converting to with to manipulate these mutexes (assuming the
lock type has its context management methods implemented in C) will
remove the possibility of these bugs occurring.