I would still see this as an instance of unnecessary complexity in the Git workflow - mostly the workflow for submitting, but not just that.
Of course, one could also argue that this is by design. Still, I don't see why a lightweight client that is feasible for the web would not also be feasible for the command line.
For example, it would be great to be able to have a checkout with reduced history. You could reduce in time and/or space, i.e. just a subtree and/or just the last 3 months. Even a distributed VCS doesn't need all history and all files as long as it has the relevant checksums.
If you haven't seen it before, check out gitless: actual research-backed simplification of the git commandline workflow.
Reduced views of files and history are super useful, but unfortunately don't work in the case where you've browsed your way to a part of the code that you seldom work on, since you're less likely to have loaded them into your narrow slice: it's still nice to be able to fix spelling mistakes far afield, and the web editing helps nicely for that.
What would help with the cases you describe, though, is a synthetic filesystem view, cache-faulted in as needed, like the one Microsoft is building. I'm pretty excited about where that's heading. https://github.com/Microsoft/GVFS for the project, https://blogs.msdn.microsoft.com/devops/2017/11/15/updates-t... for the announcement they're going to be working with Github. Pretty cool stuff.
The comment I replied to was claiming that it was the git workflows (I assume for submitting, but am open to correction) that make this cumbersome. I was pointing out that in an enormous repository (and I did mention my current employer as an example too -- and we use Git, not Google's internal tooling), just getting to the point of having the latest version of some far-flung file that you usually never touch open in your editor is cumbersome enough to make this feature a win, regardless of whether the workflows for submitting the change disappear altogether.