I hate numbered test files. Not that it isn't useful to force the ordering of some tests, but because its not then necessary to force the ordering of EVERY test. At the worst case you're back to BASIC. Observe the test suite from SQL::Statement.
Now, how much of that is really trying to order the tests and how much of it is just the order it happened to be written? Does the limit test really have to go after the functions test? Why is there a quoting test in the middle of three join tests? I see three that make any kind of sense, 00error.t (since most of the tests use RaiseError), 20pod.t and 21pod_coverage.t, which maybe go last, though its honestly not important that they do.
What's the harm? It cripples command line completion. And you've got the old BASIC problem of renumbering. I want to add a new test, where does it go? Do I have to puzzle out the implied dependencies? Do I stick it at the end? But then the POD tests aren't last any more. Do I renumber everything? Do I use a duplicate number? Do I say the hell with it and cram it into an existing test file?
Not worth it.
Realistically most test dependencies really want to express two things: Run this first and run this last. For that you have 00foo.t and zz-bar.t. 00compile.t, 00setup.t, zz-teardown.t, zz-pod.t, etc... Anything else, just write it without the number. Or if you really do have a fixed order use Test::Manifest.
If you do have tests that would do better running in order, then instead of smashing them together into one arbitrary numbering system, group them. That is, stick them into a common subdirectory and then apply the first/last numbering again. A clear candidate in SQL-Statement would be t/join to contain naturaljoins.t, morejoins.t and bigjoin.t. This has the advantage of easily letting you run all one group's tests in one shot. "prove -lr t/join".
I don't mean to pick on SQL::Statement, its just what I'm patching right now. Lots of distributions obsessively number their test files to no real advantage.