Two aspects of test ordering:

'''1. - Run Likely to Break Tests Earlier in the Test List'''

For example, run the most recently modified files first.  Just a speed optimization (though, speed in testing can be very important - it shortens the feedback cycle). See TestSpeed/TestCollector

'''2. - Order Specific Tests'''

Some tests work when run in one order, and fail when run in another order.

This is a bad thing, a CodeSmell. It usually indicates implicit dependencies in the test framework or the code under test.

Isolating tests by placing them in their own objects, or in their own processes reduces the opportunity for such TestOrdering problems.  But it's really sweeping things under the rug.