OK, as I mentioned in my comment from a few hours ago, I did delete the orphaned entries row, and all the leftover sprout* tables, plus a row in craft_elementindexsettings that had 'barrelstrength\sproutforms\elements\Entry' in the type column; none of that cleared my cp failures. I then searched all columns in all tables for '%barrelstrength%' and found a bunch of additional stuff, which I opted to delete (on dev!) one at a time to see what would happen. I don't have/need any Sprout plugins installed anymore at all, to be clear.
Deleting all the relevant rows in craft_fieldlayouts, craft_fields (plus the related rows in craft_fieldlayoutfields), and craft_resourcepaths didn't help. I finally went ahead and deleted the row in craft_queue, reluctantly, because I'm not real clear on how queue tasks work or are triggered. That did clear the error in the cp, but left me not totally confident that my search indexes were in fact up to date.
So, to be very sure, I used the CLI resave/entries command. Had to increase my PHP memory for it to be able to finish (I have about 11,000 entries), but it did, and now I've logged back into cp and I see it's working on the "Update search indexes" task again. Hooray! It's obviously going to take a while, but once that's done, I think I should also take the three hours to run a spider on my dev site here to be sure it doesn't find any 500 errors caused by my deleting database rows with wild abandon, and then I'll consider my problem solved.
After that, I'll get to do all this over again on production, while resolutely pretending I didn't see more random leftovers from Sprout Import when I searched all columns in all tables for '%sprout%'.
[Update, later: no 500 errors upon spidering. On production, it worked as a quick version of all the above shenanigans to delete anything in craft_elements with type like '%barrelstrength%' and then delete the one row in craft_queue that referenced the failed task. Having looked at what was happening in my database during the time it took to update search indexes after I resaved every single entry via CLI, I have a better sense of what's actually happening during that process, and 99% sure now that the CLI resave wasn't actually necessary. This quick fix also obviously skips over removing the various outdated Sprout-related data in my database, but For Science, I wanted to know if it would be possible to get queued tasks moving again within a couple of minutes rather than some hours, and the answer was yes... though I would not have wanted to skip the step of spidering a live site for 500 errors after manually deleting data from the database, if I hadn't taken that step on dev.]
@Ben, I'm very grateful to you for your quick reply to get me started on resolving my issue, but also please consider this comment a request for Barrel Strength to think about if there are ways to improve Sprout plugin uninstall cleanup—whether that's programmatic improvements or just making sure users know if there are steps we should take before uninstalling to prevent a situation like this. I installed Sprout Forms and played with it for just about three hours before deciding it wasn't right for what I was trying to do; it will end up having cost me considerably more time than that to be confident that the site is running as well after uninstalling as it was before installing. Thanks again.