I think this is mainly aimed at enterprise users where subversion is still very relevant.
using a new version with a few new features of an existing tool (svn) is always an easier sell than using two new tools (git, git-svn) as well, especially when one (git) has a reputation as being very complex, and the other (git-svn) looks like a hack to glue two different systems together.
Personally, I would find it more useful to sit around and watch paint peel off my wall. But then again, I didn't write a book about why open source projects should have 100-message-long votes on every line of code to be added to the project... so I clearly don't "get it".
For most of us, no. For the SVN team, other forces are at work - I'd say familiarity of the code and desire for their baby to stay relevant are big ones.
It has to be sold to me (or your typical departmental svn user). I do spend time learning new tools, but that time is limited, so I'm less likely to spend it on something that has the potential drawbacks that I raised.
FWIW, yes, I am trying out git on the side. That use of time looks worthwhile.
They haven't really mentioned exactly what will be supported by these changes, but it seems to me that without local branches, offline commits aren't really worth much. The fact that you need 5 svn checkouts to work on 5 different features at once sucks. With git-svn I can work on as many features as I want with different local branches, and they can each be based on different remote branches if needed.