Q:

Commits are left behind when branch is deleted after merge

Consider the following merge:

After deleting the 'testmerge' branch, its commits remain behind. 

Are those commits ever going to be deleted (garbage collection)? Remote prune doesn't seem to remove them...

A:

Your question most likely stems from a misunderstanding of how Git works. 
In Git, branches are mere pointers to commits. Deleting a branch may render commits unreachable (in which case they would not appear on your GitHub graph), but only if the commits in question are not contained in the ancestry of any other existing reference (branch or tag). Moreover, garbage collection / pruning of commit objects only applies if those objects are unreachable.
In this case, based on your screenshots, the repo looks as follows (before the deletion of testmerge):
-- A ----------- E [development]
    \           /
     B -- C -- D [testmerge]

Note that commits B, C, and D, in particular, are reachable from testmerge; in other words, they're contained in the ancestry of the tip of branch testmerge (commit D). However, they're also ancestors of the tip of branch development (commit E). Because those three commits are reachable from development, deleting testmerge will not make them "go away":
-- A ----------- E [development]
    \           /
     B -- C -- D

And because those commits are still reachable (from development), running Git's garbage-collection mechanism will not affect them.

