It IS NOT guaranteed! Your test cases are invalid! Case in point:
I have a table with an IDENTITY column as the PK with a clustered index on it. The table is ever increasing. It has hundreds, if not thousands of rows.
Now for all of you that think a "SELECT * FROM..." would return the rows in PK (IDENTITY) order, you are wrong!
The SQL Server optimizer, in this case will return the rows in physical block (page) order. Which in this case, will actually be scrambled. Why, you ask?
In this business case, the table has a number of NULLable columns that are filled in later. When the NULLable columns are updated with values, some rows can no longer fit in the page. Therefore, they are moved to a new page (page split). Those new pages are allocated "somewhere". Without an ORDER BY clause, SQL Server has no reason to use any index to get to the data.
Additionally, if SQL Server performs a parallel query, the rows will be returned in all sorts of random order.
For all of you developers who do not specify an ORDER BY clause, and assume, based upon your invalid testing, that the data will always be returned in the correct order, you are making a grave mistake! It is the cause of more bugs in computer systems.
[font="Arial Narrow"](PHB) I think we should build an SQL database.
(Dilbert) What color do you want that database?
(PHB) I think mauve has the most RAM.