I agree that there could be valid reasons to run V_V2. However, it implies partial quantity confirmations - there must be a reason for that to happen in the first place which should be investigated.
For example we had a process with sales of ice, were the production happens during the night based on a report of the quantities ordered on the previous day (due to limited storage capabilities of the special storage space), so we chose to switch off ATP in the sales order. The actual quantity to be delivered to customers was based on the picked quantity in the deliveries (we still needed production order confirmations to happen before the goods issue for the deliveries). There were no problems with credit blocks, because in this case we release the order against the confirmed quantity that is in fact the ordered ice quantity.
What you describe is not a bug, but a very reasonable feature - I would try to explain it the best I can.
When you release an order from credit block, you take the decision for credit risk based on the credit value. In this case the check is executed on the confirmed quantity and not on ordered quantity (there is such option via a user exit, but I understood that the client decided not to use it probably because of the negative impact on his business).
When we have a partial confirmation for an order and a subsequent block, the credit clerk based his decision on value X and released the order (the risk for the company was acceptable). After running V_V2 we get full confirmation and the value becomes X+Y. It can be that the risk for the company becomes too high, so the credit clerk should review again the credit situation and decide whether to release or not the same order. From audit point of view not blocking the order for credit again in case the value is increased would be an issue.
What I tried to point out in my previous comment (clearly I failed to express it very well) is that V_V2 is supposed to be run before the order is processed by credit department. Credit clerks run VKM4 with selection based on next shipping date - why would they release from credit an order several days in advance, when the credit situation could change several times before they have to deliver it? In some companies they even run order recheck as a daily background job, so that orders blocked for overdue items could become automatically approved in case these items were cleared in the meantime.
It really depends what logic you have implemented (it could be really well thought out and it could eliminate any possibility to abuse this functionality) - this is why SAP provides the option of defining a routine in OVA8 and the user exit on released value. There is no such thing as 'one size fits all' in credit management processing (SAP even wrote something of that sort as a comment in the sample routine 001).
Bypassing additional credit blocks in case of value increase could not only cause audit problems, but also potential losses for the company - especially considering that most of these credit blocks can be minimized by better organization and establishing internal rules.