Let's be clear here: under what circumstances is the order indeterminate? If we are talking about a single constraint with cascade, the only order of interest is the order in which the referring rows in the single referring table are addressed - because the exclusive locks on the target table must be taken before what referring rows are affected can be determined. Unless you write row by agonizing row code instead of set-based code, you have no control at all over that order in a trigger. Assuming you don't write such code, the only case of interest must then be when there are multiple referring tables. This is pretty much a minority case, so usually there is no order issue, whether you are in a high concurrency scenarion or not.

So I stick by my statement that it is usually an error to eschew cascade.

When there are multiple referring tables, either you deal with all the referring tables in at most 3 triggers or you can't determine the order because you can't specify more than which tables are hit in the first trigger and which in the last, so your triggers may need to be a bit unwieldly if there are more than 3 referring tables and you want to force the order.

Of course if you are in a situation where you need instead of triggers (for some reason or other) you don't have the option of using cascade - but instead of triggers on tables as opposed to views are pretty rare.