The hash is a hash of the data in the repo at that point in time. Its done to be a) unique and b) to guarantee the data. SVN's sequential number does a) but tells us nothing about the data. On the other hand, git, while good at b) cannot quite guarantee a).
You could almost say that there are three numbering requirements:
a) Uniqueness guarantee
b) Integrity guarantee
c) Sequential ordering guarantee
I don't know whether the identifier that is yielded as a result of (c) really has to be a pure number, as long as it can be parsed as being sequential: while I routinely incorporate Subversion revision numbers into build identifiers I'm used to having e.g. 12345M and would be surprised if anybody tried manipulating them under scripted or program control.
Having said which and bearing in mind a suggestion (admission?) that somebody made in a PM, one possibility would be if an Svn-revision-surrogate actually showed a Git hash plus the number of subsequent commits... it might not be completely robust under all possible scenarios but it would allow a subteam investigating e.g. a trunk regression to say "we're at #1a2b3c4d.56, but if we revert 10 commits to #1a2b3c4d.46 the problem doesn't occur".
In some ways that mirrors some of the comments I've made in the past relating to conferencing systems, where it's enormously easier to thread and xref messages if message identifiers are guaranteed consistent from the POV of all users: SMF (i.e. like this forum) complies with that, Usenet doesn't unless it can be guaranteed that all messages are stored on a single locally-accessible server. Also some of
https://en.wikipedia.org/wiki/Tumbler_(Project_Xanadu) might be relevant.
MarkMLl