Hey, great question!
TL;DR; (and kinda “non-answer-answer”) because this is not aim of the rollup-geth
I think it will be easier to give you “real answer” if I explain how/why this initiative was started.
Today, L2s fork geth and build on top of it, either using it as a library (e.g., Arbitrum) or mimicking the CL-EL relationship (e.g., OP Stack). Maintaining these forks is costly, especially when upstream changes from geth need to be merged. The more divergent an L2 fork becomes, the harder this process gets.
Take the example of implementing an EIP/RIP like the L1SLOAD precompile. While it might bring nice features to an L2, implementing it independently increases the cost of maintaining that fork. Over time, these costs could slow down the adoption of useful EIPs/RIPs, as every L2 would need to manage this on their own.
I suspect this is why the implementation of some of these EIPs/RIPs has stalled over time. Each L2 must implement desired EIPs/RIPs on their own and pay the cost when merging with the upstream.
Alternative would be to implement some of these in geth but some EIP/RIPs (like above-mentioned L1SLOAD) simply don’t make sense on L1 (and if implemented as a part of the protocol then all the clients would need to implement them adding to the L1 bloat).
rollup-geth aims to solve this by serving as a shared foundation where these kinds of updates can be “centralized”. This reduces the burden on individual L2s and allows them to adopt improvements more easily. In the future, if the ecosystem demands it, we could explore diverging further from geth.
For example, not needing a separate consensus and execution client, but instead both operations run in the same process.
Could you elaborate on the benefits you foresee from this? Many L2s have unique consensus mechanisms designed for their needs, and it’s unclear to me what value this integration would bring.