Thanks for the nice context Diego. I would like to add some more of my personal opinions here as well.
As much as the foundation would like to work on various different projects, we do have limited resources in terms of engineers and we have to work on the most urgent and highest priority projects first. Having an actual production network means that a huge amount of resources are needed to maintain and stabilise the network. A lot of this work happens in the background and the end users may not see the immediate benefit of it. However, the benefits are significant in terms of reducing the occurrences of high severity issues; improving monitoring and observability of the network; addressing technical debt so we are more confident about the correctness of the code and can build new features easily; etc. In many cases, we are forced to prioritise such works over working on new features.
Further, my opinion is that the project of increasing the stable memory size allowing canisters to soon hold up to 300GiB of storage may have potentially helped further reduce the urgency of BigMap. I have not seen many canisters in production with a huge state so suspect that it will be some time before we see canisters that need to store more than 300GiB of state.
And finally, I would love to see the community actually build / experiment with the different designs of BigMap. I don’t think anyone can claim to know for certain what precisely is the best way to build BigMap that can span span 100s of subnets and manage petabytes of storage. So we need to explore different ideas.