You're right, updating > stale_percent rows in a table will mark the stats as stale:
create table t as
select rownum c1, date'2000-01-01' c2 from dual
connect by level <= 1000;
exec dbms_stats.gather_table_stats(user, 't');
select coalesce(stale_stats, 'NO') from user_tab_statistics
where table_name = 'T';
COALESCE(STALE_STATS,'NO')
NO
update t
set c2 = sysdate
where rownum <= 200;
commit;
exec dbms_stats.flush_database_monitoring_info;
select coalesce(stale_stats, 'NO') from user_tab_statistics
where table_name = 'T';
COALESCE(STALE_STATS,'NO')
YES
1. No. If you only change this column and it's not in your where clauses it doesn't matter this is out of date. All your other stats are still "good". So the optimizer should still pick the "right" plan.
Though this table will be picked up by the regular stats gathering job. Which leads to some redundant work.
2. If the stats being stale concerns you, you could increase the stale_percent for the table:
exec dbms_stats.gather_table_stats(user, 't');
select coalesce(stale_stats, 'NO') from user_tab_statistics
where table_name = 'T';
COALESCE(STALE_STATS,'NO')
NO
exec dbms_stats.set_table_prefs(user, 't', 'STALE_PERCENT', 50);
update t
set c2 = sysdate
where rownum <= 200;
commit;
exec dbms_stats.flush_database_monitoring_info;
select coalesce(stale_stats, 'NO') from user_tab_statistics
where table_name = 'T';
COALESCE(STALE_STATS,'NO')
NO
Eventually they will become stale though.
Alternatively you could look at selectively locking stats on the table.