Why Oracle does not allow rollback of DDL statements?

Question

I have always been surprised why Oracle does a implicit commit when DDL statements (e.g create table …) are executed. DDL statements simply write information (insert, delete and update) to data dictionary, so why DDL statement cannot be rolled back. Am I missing some thing?
I was learning SQL Server few months ago and I noticed that SQL Server does allow rollback of DDL statements if I am not mistaken. It lloks like there is something in Oracle architecture which prevents rollback of DDL satements. Rollback of all staements should be allowed not just of DML statements.
Appercaite your insight.

Answer 1

If you drop a 500 million row table (and let's assume you're not using the Recycle Bin, which is a different matter entirely), how do you propose to re-insert all 500 million rows if you were to be allowed to rollback the drop command? Same thing goes for a truncate command.
I'm not saying there aren't workarounds (the Recycle Bin is precisely one of those), but it's certainly problematic. You could very well reverse the transaction ('delete from TAB$...') quite easily... but reversing the other consequences of that transaction is a lot more awkward. Therefore, it is certainly logical to declare such transactions irreversible and thus to imply a commit, both before and after.
Or take it from another philosophical angle: a transaction that doesn't commit (or rollback) takes exclusive row-level locks that are held indefinitely and which will prevent other people from doing DML on the same rows, yes? Well, how do you fancy having an 'alter table' statement sitting around, uncommitted, in the data dictionary? Some process (or your users) are wanting to insert rows into this table, but the uncommitted alter command means that they can't acquire the shared table lock they need in order to be able to do so. One uncommitted DDL can seriously gum up the works, in short.
Dictionary tables are not like ordinary user tables, because whilst what I do in INVOICES very likely has no impact on what you do in SALARIES, what I propose to do in TAB$ very definitely impacts what you might need to do in TAB$. Under those circumstances, it's a jolly good thing that Data Dictionary DDL doesn't leave a trail of uncommitted transactions hanging around! And the mechanism to achieve that 'good thing' (i.e., auto-committing) means such transactions must be immediately irreversible.
Fair enough if other databases have chosen to handle things differently: their prerogative, of course. My point is simply that there is logic in NOT being able to roll back DDL statements, too, and it's a legitimate choice to have made to handle things in this way, too.