I've advocated for this approach before, I think it's definitely true that a single code base is an optimal place work out early architectural decisions so you

I've advocated for this approach before, I think it's definitely true that a single code base is an optimal place work out early architectural decisions so you can optimize the interfaces and separation before committing to the overhead of multiple repos and deploy stacks. One of the challenges, though, is making sure the whole team understands the vision and doesn't violate the intended separations. Working primarily in Rails, I've found it to be pretty terrible in this regard, both due to ruby's global namespace, but also just because there are no conventions to properly separate app-level modules (Rails Engines are a second-class citizen). Django is significantly better since it gives you apps as first-class citizens, and because of Python's explicit module import, but even still you can quickly end up with a ball of mud if you're not careful.