I think `creation_date` *is* a default/universal sorting, unless `activity_date` is available. <sup><sub>(But you know what they say happens when you "ASSUME".)<sup>&ddagger;</sup></sub></sup>

**Evidence for:**

 - Seems like it would be required if paging is going to work well.
 - This [post has 753 edits][1] ([759 revision entries][2]) and the creation dates are all in descending order.
 - This [post has 429 edits][3] ([502 revision entries][4]) and it has at least 1 edit of each subtype ([title, body, tag] x [edit, rollback] + suggested edit). The creation dates are all in descending order.
 - [Other routes *seem* to sort by `creation_date` although sorting parameters are not supported by the route][5].
 - Likewise, [`/events` sorts by `creation_date`, descending][6], despite that being [unmentioned in the livedoc][7].
 - This [way old answer about API version 1][8], has the lead developer saying:
  > Because sorting by dates is much more common than by name, ordering is descending by default.

<br>
**Evidence against:**

 - The various inconsistent behaviors as documented in the unresolved bugs here on Stack Apps. And on Meta Stack Exchange, and on Meta Stack Overflow.

<br><br>

----------
<sup><sup>&ddagger;</sup> They say that you've made a cost-effective branching decision based on knowledge and experience. And that it in no way precludes you observing-for and reacting-to signs that the assumption was false.</sup>


  [1]: https://stackoverflow.com/posts/4673436/revisions
  [2]: https://api.stackexchange.com/docs/revisions-by-ids#pagesize=100&ids=4673436&filter=!*JxbFHyEBcq*hArY&site=stackoverflow&run=true
  [3]: https://meta.stackexchange.com/posts/3122/revisions
  [4]: https://api.stackexchange.com/docs/revisions-by-ids#pagesize=100&ids=3122&filter=!*JxbFHyEBcq*hArY&site=meta&run=true
  [5]: https://stackapps.com/a/8196/7653
  [6]: https://stackapps.com/questions/3151/sorting-the-event-stream
  [7]: https://api.stackexchange.com/docs/events
  [8]: https://stackapps.com/a/2233/7653