What disrupts the inherit logic order of autoincrement that leads to illogical ordering of ids in the absence of an ORDER clause?
I'll just elaborate on @a_horse_with_no_name 's comment. A table (relation) is a set of rows (tuples). By definition, a set is unordered. Asking what the next row is without specifying what you mean by next (ORDER BY), is like asking what colour joy has (well when it comes to power tools everyone knows that it is green and black ;-). 

Assume that no rows reside in memory and that another connection reads id=186 into memory. Now your query asks for:

select id from T limit 1;


What would you consider the most sensible thing for the DBMS to do, return 186 from memory, or read a bunch of rows from disk to return the lowest id?

What's the benefit of treat a table as unordered one might ask? The optimizer tries to execute the query as efficient as possible. It can re-arrange the query in a number of ways, as long as it does not violate the semantics of the query. If it would have to take the ordering into consideration, it would severely cripple the freedom to choose the most efficient plan for the query.