It's because we're smart :-) Well...not so much me, but the optimizer is.
Before a query is optimized, it goes through a phase called "transformation" where we look for ways of re-writing the query which would potentially give more options for optimization *without* changing the intent of the SQL.
Here's an example
SQL> create table t as select * From dba_objects;
Table created.
SQL>
SQL> create or replace view v as
2 select * from t
3 order by object_name, object_id, created;
View created.
SQL>
SQL> alter session set events = '10053 trace name context forever, level 1';
Session altered.
SQL> explain plan for select * from v;
Explained.
SQL> explain plan for select * from v order by owner;
Explained.
The '10053' instructs the database to dump out optimizer information. You can see our view V with an order-by in the defintion, and then I looked at two potential queries on it.
In the trace file from the 10053, we see the following
Final query after transformations:******* UNPARSED QUERY IS *******
SELECT "V"."OWNER" "OWNER",
"V"."OBJECT_NAME" "OBJECT_NAME",
"V"."SUBOBJECT_NAME" "SUBOBJECT_NAME",
"V"."OBJECT_ID" "OBJECT_ID",
"V"."DATA_OBJECT_ID"
"DATA_OBJECT_ID",
"V"."OBJECT_TYPE" "OBJECT_TYPE",
"V"."CREATED" "CREATED",
"V"."LAST_DDL_TIME" "LAST_DDL_TIME",
"V"."TIMESTAMP" "TIMESTAMP",
"V"."STATUS" "STATUS",
"V"."TEMPORARY" "TEMPORARY",
"V"."GENERATED" "GENERATED",
"V"."SECONDARY" "SECONDARY",
"V"."NAMESPACE" "NAMESPACE",
"V"."EDITION_NAME" "EDITION_NAME",
"V"."SHARING" "SHARING",
"V"."EDITIONABLE" "EDITIONABLE",
"V"."ORACLE_MAINTAINED" "ORACLE_MAINTAINED"
FROM (SELECT * /* MSQ_NON_UNPARSED_SELECT_LIST_FOR_VPD_VIEW */
FROM MCDONAC."T" "T" WHERE 1=1 ORDER BY "T"."OBJECT_NAME","T"."OBJECT_ID", "T"."CREATED") "V"
Final query after transformations:******* UNPARSED QUERY IS *******
SELECT "T"."OWNER" "OWNER",
"T"."OBJECT_NAME" "OBJECT_NAME",
"T"."SUBOBJECT_NAME" "SUBOBJECT_NAME",
"T"."OBJECT_ID" "OBJECT_ID",
"T"."DATA_OBJECT_ID" "DATA_OBJECT_ID",
"T"."OBJECT_TYPE" "OBJECT_TYPE",
"T"."CREATED" "CREATED",
"T"."LAST_DDL_TIME" "LAST_DDL_TIME",
"T"."TIMESTAMP" "TIMESTAMP",
"T"."STATUS" "STATUS",
"T"."TEMPORARY" "TEMPORARY",
"T"."GENERATED" "GENERATED",
"T"."SECONDARY" "SECONDARY",
"T"."NAMESPACE" "NAMESPACE",
"T"."EDITION_NAME" "EDITION_NAME",
"T"."SHARING" "SHARING",
"T"."EDITIONABLE" "EDITIONABLE",
"T"."ORACLE_MAINTAINED" "ORACLE_MAINTAINED"
FROM MCDONAC."T" "T"
WHERE 1=1 ORDER BY "T"."OWNER"
In the first example, we simply ran the view with its order by as per the defintion. With the second example, the optimizer detected that there is no benefit in ordering based on the view definition, because we're about to override it in the outer query. So the query was transformed to reflect that.