Why storing product fees in another table is preferred?
If the range of fees is guaranteed to be fix - as well as the fees themselves, you might be fine with having them as columns in your product table rather than as rows in additional tables. Otherwise, you will need to adjust the schema and your code in order to add a new type of fee.
Once, you have separate tables, maintaining, e.g., periods, a particular fee value is valid for, is simple (even though, it might require one more table and one more join each). Just imagine trying to do this using columns.
As always in (database) design: You need to balance (application) requirements, efficiency/effectiveness of your solution, flexibility down the road, etc. based on your domain('s characteristics as valid over the lifetime of your system).

In general, this is an example of data (de)normalization…