Both negative and positive impacts are linked to stock moves. Positive or negative just depend on actual destination and source locations.

Simultaneously, storing the fields is hardly a good idea: 

1. Although they depend mainly on stock moves, it would be extremely difficult to catch the changes (each state change, create, update, etc - simple api@depends probably would not be enough). There is a significant chance that certain triggers would be missed;

2. Those fields are context-dependent. In a significant number of methods, no just product quantity is needed but quantity for a definite warehouse or stock lot. Moreover, quantities are calculated for any real date what is impossible if fields are stored. Finally, actual figures are access-dependent (different user and users different companies might have different final values). So, you would need to re-develop all of those methods. This is extremely complex and error-prone;

3. There are issues with product template / variant inheritance. That Inheritance would a be an obstacle to store values.

There are critical reasons why fields are made non stored. Avoiding that would jeopardize procurement, user experience, etc.

If you anyway wanted to have some stored figures, it would be better to introduce own fields for that purposes. You may populate such fields both by compute methods (with own calculation logic) or regularly by cron jobs (e.g. just by copying non-stored values).