I don't think kind of shallow changes to the test suite should be backported.  They probably shouldn't have been done at all.  When you change code, the tests are a safety net.  When you change tests, you have almost no safety net at all.  If the original test was developed using test-driven-development or for a bug-fix, then it was demonstrated to have failed at one time.  But when pointlessly refactored, the revised tests have no longer been demonstrated to actually detect to original underlying bug.  

If the whole point of "specific asserts" is to have better error messages on a failure, then we should wait until there is an actual failure to make the change.  Otherwise, this reduced the reliability of the test suite with zero benefit.  Most of these tests will never become broken (I can't recall the last time any of them failed) and if they did, their existing message would suffice.

Another reason this should be done is Guido's notion of "holistic refactoring".  The idea is that someone shouldn't travel through modules making shallow changes.  That work should be deferred to the module maintainer to be done in the course of normal deeply thought out work on the module.

The last reason these kind of changes shouldn't be made is that undoes work by the person who originally wrote it, making the code less familiar to them when they come back.  For example, most of the tests for sets are written in a way that reflects how I was thinking about the problem when I wrote it.  If someone comes through and renames the variables, rewraps the lines, switches the choice of assertions, etc.  Then they make it more difficult to recover the original line of thinking by the designer.  Put another way, no one likes to have code they're written needlessly scrambled around.  If there is a real bug fix, then yes.  Otherwise, shallow wholesale search and replace missions should be approached reluctantly.