"Another unrelated problem I have is: the data in the table affects
directly a calculation, if any column is added, the calculation must
consider the new column/columns."
What you meant to say was "Another completely related problem is ...". Because this statement highlights the profound implications of your proposed implementation. Dynamically adding a column is the easy bit.
The difficult bit is the concomitant need to conduct an impact analysis of the code base and assess all the SQL which references that table. After all, it is not enough to include the new column in that calculation. There may be other SELECTs which need to be amended (e,g, reports). And of course you need to get data into the new column, so that means amending UPDATE and INSERT statements. This sort of thing is hard enough to do with a human being in charge. Writing dynamic SQL to do it automatically? Madness.
I do hope you're not writing your application for any organisation which has responsibility for my own tax affairs.
Anyway, your problem derives from treating new data as a structural change, rather than what is it, a content change. It is quite clear that a table declared as yours is, with repeating columns (TAX1, TAX2, TAX3), is a part of a poor data model and needs further normalisation.
It is true that this might make your tax calculation more complicated, but that is a good thing. The complexity should be in the business rule implementation not the data model. At least this way the complexity is constrained to a single program unit instead of being strewn through your application's CRUD functionality.
For the sake of completeness, here is the path to the Mountains of Madness:
create or replace procedure add_new_col as
n pls_integer;
begin
select count(*) into n
from user_tab_columns
where table_name = 'YOUR_TABLE'
and column_name like 'TAX%';
execute immediate 'alter table your_table add tax'||trim(to_char(n+1))||' number';
end;
You can give the user execute privileges on this procedure without granting them broader rights on the underlying table.