I’ll note this here as my stance, coming from the prototyping team (but my personal opinion) and thus not from a client team:
This EIP solves the problem of the max code size partially (it still has an upper bound). However, due to EIP-7825 and due to possible increases of code size deposit cost (gas repricing) this limit is already implicitly there, being the tx gas cap of EIP-7825 (2^24) and the code deposit cost per byte (200) the limit is ~83KB if we would have no capped limit of EIP-170`s 24 KiB. Due to gas repricing for storage costs this might decrease. Note that this analysis does not take into account the extra cost like tx intrinsic cost, memory, calldata, etc.
It is clear however that we should increase the max code size, as dealing with code which needs more than the limit of 24 KiB is now either a task of the compiler (not sure if this is already being done) or developers have to figure this out themselves (using the diamond pattern). Also the limit imposed years ago really has to be lifted.
However I feel that this EIP solves the problem only short-term. The problem I see is that you always pay for large contracts, even if you don’t use the code. It’s only “fair” if the extra cost you pay is cheaper or close to what you would pay without this EIP. Without this EIP, you would need extra contract(s) to call+load (paying EVM opcode overhead + warming up that account).
I feel that this EIP will, once shipped, first be used “greedily”. Then after a while people realize that based on the usage patterns of the contracts they deployed, it makes optimize the sizing of the contracts and what code is put together to reduce the gas costs which users pay.
I’m not sure what this means in practice, but I think that the size of contracts we will see in practice are close to the current max of 24 KiB, where the oversized contracts make sense because (1) all the code is always being used and (2) it is more expensive to split up the contracts in 2, because of the EVM overhead costs + warming of that second account.
Therefore after analysis of these > 24 KiB contracts developers will group together contracts which are, if you would execute the same (but now gas-golfed/optimized) code (but now optimized over split contracts), cost less than the current. So I think that due to gas golfing we will see only slightly oversized contracts. Only contracts which always use all the code will be “largely oversized” (> 48 KiB).
Although already DFId, EIP-2926: Chunk-Based Code Merkleization makes users pay for what they use, and not pay for unused code. It also removes the code size limit at all (so future-proof). I want to add that my feeling is that this EIP 7907 will add a feature which will only be used short-term (adds code debt). This EIP will solve the drastic need for the code size increase, but I think this is a short-term solution, and from a long-term protocol perspective I would rather have a long-term solution like EIP-2926.