How can I allow editors to manage many taxonomies while choosing which terms to boost and which to make visible?
My preference is to use 3 fields. I'm not sure I think it's ideal, but I think it's actually an easier UX and a better data structure than 1 field (or subentity) with taxonomy ref plus additional checkboxes for primary and display with each tag. 

On the surface, it may seem like 1 field would be better, but I think that's actually an illusion. The two main users I'd consider here are developer and editor, and I think one complicated field is bad for both of them. For developers, it's going to be more difficult to determine the search terms or display terms when you try to get them in code with one complicated field vs 3 separate fields. It's also going to be more difficult for editors, they won't be able to scan and see all search terms or all display terms easily.

Field 1: Tags
This is the master field, it has all the tags that would be in either of the other two fields. If you're generally checking if the content has a tag, you'd check here.

Field 2: Display Tags
This field is a subset of Field 1 tags and its only purpose is determining which tags display.

Field 3: Search Boost Tags
This field is also a subset of Field 1 tags and its only purpose is boosting search results.

Custom Field Widget
Create a new field widget to be used with the display tags and search boost tags fields. This widget displays tags with checkboxes and is limited to only the tags in the first, master tags field. Also have the widget update its options via ajax whenever the first tag field changes.

This approach creates an easy interface for editors, keeps all the data easily accessible for developers, and limits special custom coding to just the field widget. (Bonus: you now have a cool field widget in your collection that you can use elsewhere in similar situations.)