While you can link Differential revisions to Maniphest tasks, Maniphest only displays a dumb list of the tasks. Showing their status would make the tasks much more useful at a glance.
My very particular usecase is perhaps out of your target audience, but let me attach the result first, as I think it's desirable:
{F277541}
The reason I really want this, is because I'm hoping to be able to use Differential to manage reviews of patch//sets//, in the style of most low-level Linux projects. Projects such as the kernel, Wayland (which I want this for), X.Org, GNOME, etc, each use Git with local mutability but remote immutability, to produce patchsets. That is, whilst developing, we break each patch into small, digestible, changes which are easily and independently reviewable. These patchsets are meant to be considered as a whole, but for review purposes, each patch is considered individually.
This is probably a good example, where the combined changeset would've been much too large to comprehend in itself, and also where many of the separate changes required entirely separate reviewers: http://lists.x.org/archives/xorg-devel/2011-June/thread.html#22868 - hopefully it goes without saying that we'd love to move this off mailing lists and on to better tooling.
Differential's immutable mode falls down here, because it still presents the result of the entire patchset, not the individual patch for review. I don't expect Differential to grow support for this separate mode, since it seems to run contrary to all your usecases and would present a lot of UI work, but this tiny change would at least allow using Maniphest tasks almost as JIRA-style epics, to track the review status of each patchset and co-ordinate landing those patches. ('arc land' is also useless to us in a number of cases, because the merge process often involves multiple stages of merging through sub-trees, before it lands in the master repository.)
I do have a patch which implements this, however it's pretty horrendously ugly, directly bashing the TaskDetailView controller. I suspect a more reasonable approach would involve the PHID's renderLink method. I haven't attached it as your contributor guidelines make it incredibly clear that I shouldn't at this stage.
Thanks for considering this. Let me know if you consider it useful and we can work out how best to land it.