The question of whether the Civi community mirrors its technical modularity is hard for me to assess, as I'm not a technical contributor. At the highest level of abstraction, I can say that it does: there is a documentation team, which is divided into people working on end-user documentation and developer documentation; there are developers. That's the end of my concrete first-hand knowledge that I can be totally confident in asserting. But I can make some educated guesses based on my observations over the course of my participation: developer teams are also (informally) subdivided into those working on specific features or projects. Those teams seem to be ad hoc and ephemeral, with people reassigning themselves to new teams or ending their active contributor role as features are completed. There does seem to be one ongoing developer sub-team, which is the API team.
Beyond that, as to lower levels of granularity, I can only speak to the end-user documentation team. First, however, modularity in technical writing has interesting differences from code that are instructive to note: + Cross-referencing, indexes/tables of contents, and other pointers within documentation are very important to usability, but they will not literally make or break the project the way that a line of code calling a broken function in another part of the code will. + Where one section of prose ends and other begins is not always clear. + Whether or not a piece of documentation "works" is open to interpretation, and in fact often varies by user for the same piece of writing. This complicates the approval of changes. + Documentation can be incrementally improved by small prose changes in ways that are extremely unlikely to cause problems in other areas of documentation or with the documentation as a whole.
Overall, most Civi work happens asynchronously, as demanded by the constraints of the space- time continuum in a global community. However, a lot of work also gets done in sprints, week-long gatherings of developers and/or writers working side-by-side on a set agenda of features/projects/changes. I have now experienced working on Civi in both of these environments, and I have to say that the modularity of prose, even as complex as it can be, is not much taken advantage of to get work done asynchronously---maybe it's that we're all busy with other things in addition to our Civi work, but things seem to move A LOT slower. Whereas at a sprint I could just make a verbal suggestion, have a quick conversation with the documentation team lead, and then execute something, in the asynchronous distance collaboration setting, everything involves an email chain, a document with proposed changes, comments on the proposed changes, and on and on. While this is actually a good fit for chipping away at a long to-do list over the course of the semester, it does not feel all that productive in terms of actual contributions made and incorporated.
It's also worth noting that the structure of my contributions this semester is quite ad hoc: I am tasked with rewriting a lot of the copy on the project's website, which of course has a CMS---but not a version control system. So I came up with a system: a Google docs spreadsheet to share my roadmap and the status of the work, and Google docs for each piece of revised content. Supposedly I was going to be quickly and efficiently posting new content into the CMS, but the approval process has gotten quite bogged down (maybe because we didn't fully discuss how that would work beforehand?). My guess is that if I were submitting code patches, the existing review and merge process (not that I know exactly what it is) would make things much more efficient. And if I were contributing new end-user documentation to the wiki or improving existing pages, no approval process would be necessary.