"if you have suggestions on gaps in specific articles let us know and we'll work with you to make changes. [...] But we read through all this feedback, so it's helpful to keep bringing up issues that you think need to be taken more seriously..."
Why again is the ball put in our yard as if we are telling you something new? This forum and even this thread is filled to the brim with issues that point out what is wrong with the documentation: it's shallow, it's not specific (I don't know how many times I must repeat that e.g. any official information for the spreadsheet TEXT function format is totally missing [I've posted my own spreadsheet  with a summary of formatting characters now so many times people must be starting to believe it is official; and don't you dare compliment me with the effort, not after it has been so for so many years!]), there is simply information missing (e.g. how absolute and relative cell spreadsheet references can be used or open ended ranges), there is no simple overview of how sharing and publishing actually works, information e.g. about limits and sharing is scattered and so on. And what is worse one needs to know what to look for - and how this is worded in the help - to be able to find anything in the help (did you e.g. know that spreadsheets are sometimes are called workbooks, and that such is used seemingly at random in the help).
What's really frustrating is that you - the Googlers, Guides, Staff, Team - absorb the input in a most cordial and pleasant way but that it then really takes ages for something to change, and if something changes it happens in silence.
I'm maybe to old-fashioned or simply too old but I think that a software product like Google Docs is not simply the software, it is also the documentation and the customer service that are equally important. What good is it to use users to get new features if we can't know how to use the existing features to their fullest, what good is a product for which it takes ages to process bug reports - which we still can only post in a scattered fashion in this forum, and of which we can't follow their repair process?
I understand everything you say about don't having the staffing - but why then give priority to development of new (sometimes/too often half-baked new features). Urge your programmers to document their existing work - if they were properly educated this is as much a requirement as the programming work itself - this is a win-win-win for programmers, staff and users alike because everybody gains when software is properly documented (I should not have to explain why, but if you think I should I will). Programmers also must take more pride in their work, the way some bugs and issues keep dragging on or are fixed and re-appearing shows us as outsiders they don't care if it works or not - there's always a new iteration, so why bother (which may be a totally wrong impression, but if one is confronted with the same problems over and over again, what else can one believe.
I really hope you will start to make an effort to make it all - documenting, bug repair, new features - better in the future. But we need a token of this real soon. You could e.g. create a blog to be used by the developers and staff in which very regularly is reported about development progress, (remember how long it took to get the 'real soon now' Flowchart connectors) about bug fixes, and about priorities, and make this blog accessible to Google Docs Guides and TCs so these at least are aware of 'the current state of affairs' - that is if developers and staff take this seriously. That way at least Guides and TCs alike are in the loop when it comes to what's going on...