Case 1) you can use USING
Case 2)
When SQL becomes a compiled language perhaps this can be optimised out, but until then CPU cycles are required to replace your programmers brain making stuff slower. Until then lets stick to Postel's Law 
Honestly, I don't understand why this is a problem (the error message is clear). But it is, for a lot of developers. I won't insist on this, but before just saying "no", please take a look at StackOverflow or similar sites.
No matter how it works, there will always be complaints on resources like StackOverflow, because people only care about their scenario and ignore any other possibilities.
Say you introduce the "optimization" for the first case. The first complaint will immediately be something like "why does the query work with t1.id = t2.id, but fails with t1.id = t2.id or t1.id is NULL?!" , especially if the query is generated by an application and can take various forms. Same with the second example.
There are so many possibilities and variations, "what if this", "what if that", some of which are fairly subjective, it will be a mess if the server starts trying to make such decisions.
The first example, with ON is also ambiguous:
create table t1 (a int, b int); |
insert t1 values (1,1),(2,2),(3,3); |
create table t2 (a char(10), c int); |
insert t2 values ('1 hundred', 100), ('2 hundreds', 200); |
select * from t1 join t2 on (t1.a=t2.a); |
But even USING doesn't solve it:
select * from t1 join t2 using(a);
|
+------+------+------+
|
| a | b | c |
|
+------+------+------+
|
| 1 | 1 | 100 |
|
| 2 | 2 | 200 |
|
+------+------+------+
|
select * from t2 join t1 using(a);
|
+------------+------+------+
|
| a | c | b |
|
+------------+------+------+
|
| 1 hundred | 100 | 1 |
|
| 2 hundreds | 200 | 2 |
|
+------------+------+------+
|
So, I'd agree that ON can do the same as USING when resolving column names.