As I said, the optimizer is very cautious about transformations like table elimination. Mistakes here can lead to massive wrong results problems. Relying on constraints is the safest way to do this.
Oracle Database relies on constraints to determine if a table is key-preserved. Note that a successful update does
not guarantee a table's key-preserved. From 21c up there's a runtime check to see if a row has changed more than once:
CREATE OR REPLACE VIEW vw_dept_empcount
AS
SELECT d.dept_id,
d.dept_name,
d.emp_count AS d_emp_count,
e.emp_id as e_emp_count
FROM dept d
LEFT JOIN emp e
ON d.dept_id = e.dept_id;
insert into dept values ( 10, 'test 1', 0 );
insert into emp values ( 1, 'test 1', 10 );
update VW_DEPT_EMPCOUNT
set d_emp_count = e_emp_count;
--1 row updated.
insert into dept values ( 10, 'test 1', 0 );
insert into emp values ( 1, 'test 1', 10 );
update VW_DEPT_EMPCOUNT
set d_emp_count = e_emp_count;
select * from VW_DEPT_EMPCOUNT;
--ORA-30926: The operation attempted to update the same row (rowid: 'AAARlqAAMAAAACnAAB') twice.
In this specific case where you've grouped by the join columns in the outer-joined table then it may be possible to eliminate it, though this feels like a niche request to me.
You're welcome to file an ER if you think this use case is valuable to you.