FWIW I had this discussion with the ASE guys some time ago. IMO, insert with order by should be guaranteed up to the point where the data is physically inserted by the access layer, if the storage layer changes the order then fine it changes the order (clustered index may determine this etc). Primarily you may want order on insert a number of reasons, 4 that spring to mind are:
A) insert with order by under rowcount - you expect (demand?) the first row as defined by the order by to be inserted
B) insert with order by whilst generating identity values - you expect the identity valuyes to be incremented as per the order by columns.
C) insert with order by and NOT selecting the order by columns - OK, for this one you are going to make an assumption that rows are inserted into a given table in the order defined by the order by column and of course you would then ensure you don't have anything in the table or index structures that could change the order.
D) Concurrency, so using an index that provides the order.
The purpose of the order by with insert is to present the rows to the access/storage layer in the order defined by the order by clause. If the access layer for any number of reasons determines the data needs to be physically stored in an alternate order then so be it, but A) and B) on the list above have to work as required.
The access->storage layer then effectively becomes the client of the select query, so the select with order by has to be preserved from the query processing perspective.
I think the ASE CR was 620806 if my memory serves me correctly.
In essence it is not a debate about storage, it is about query processing.