I suggest drawing a fairly sharp distinction between "in-context help" and "onboarding". The vast majority of users would benefit from in-context help, if that answers either "What does this specific feature [of VE, primarily] do?" or "How do I do this [in VE, primarily]?" By contrast, onboarding is (by definition) for new(er) editors, and its focus is on different things: "How can we help you do something useful, rather than futile?", "Here is a policy or guidelines that you don't seem to be aware of?", and similar.
For in-context help:
(a) Some time ago I suggested adding clear, helpful information to all of the editing options in VisualEditor. That followed a limited attempt to do so by the WMF developers - see, for example, in the page options menu, when "Options" is selected, the small "i" with a circle around it, on the right side of the dialog box. The critical parts of implementing such a system, I believe, are (a) adding "hooks" in all the right places (the small "information" icons), (b) enabling administrators of local wikis to add and edit the displayed text [raising translation/maintenance of "core" message issues, but I digress], and (c) enabling those administrators to add links within the text, so those more inclined could go to help and/or guideline pages.
(b) For "How do I do this", it could be very helpful if the Help icon in VisualEditor allowed an editor to select from (say) 50 to 100 different choices ("How do I add a footnote?"; "How do I cite the same source in more than one place in an article?"; "How do I add a category to an article") and, then, in the best of all possible worlds, see a brief screencast showing exactly how to do that thing.
There is, unfortunately, a larger issue. I'm sure that WMF sees the challenge as designing tools for in-context help and for onboarding, and then letting the community use these. Unfortunately, the English community (among the most active) has demonstrated, convincingly (in my opinion), that it's incapable of maintaining help pages - "maintaining" in the sense of "keeping current with the software changes that developers implement". For example, I'd give good odds [without having looked] that the vast majority of help and info pages for editing don't give at least equal weight to VisualEditor compared to the classic wikitext editor - yet WMF is in the process of introducing yet another type of editing software.
There is a solution to this problem, which I mention for the sake of completeness: WMF should take responsibility for core documentation, including in-context help, and including translation, for user interfaces. In other words, where WMF provides cross-wiki functionality, it should provide cross-wiki documentation. (Policies, guidelines, and processes that are wiki-specific would remain fully the responsibility of the local wiki to maintain.) Assuming that additional responsibility would cost WMF on the order of several million dollars a year [more to start, less ongoing], money that WMF clearly has. That wouldn't eliminate the role of the community in improving in-context help and other documentation management by the WMF; the community would have a supplemental role (as in, for example, "feel free to edit this to improve it").