You're probably correct and it generally won't cause too many issues. Except for when I figure out how to break things in new and creative ways... ;)

But for most themes, it also means that there's a lot of additional cruft that could accidentally be sucked in by parsers: header images, menu items, etc. as well as additional body elements below the content, including the comments, footer, widgets, other plugins, etc. Having it canonically further into the structure narrows down the scope of things that could potentially go wrong, particularly as it gets tested in a growing circle of themes that will eventually use it.

Some of it comes down to what one should expect h-entry to contain versus what one should expect e-content to contain just after it. Where do most themes put author information for the author h-card? You'd want h-entry to contain that as well as the publish time and other meta data too.

The other issue to possibly consider in terms of conflicts is how non-compliant themes which style on the older hentry (or other microformats) may behave/misbehave going forward. These may be lost causes, but could they potentially be "fixed" by injecting h-entry further down? If newer parsers look for mf2 over mf1, then not including hentry (presumably a second time) and injecting h-entry into the correct spot would override the potential error.

I ultimately defer to your better judgment...