It would be more appropriate to link Screen Sections with Data Structure Entities instead of Entities.
The link with entities is weak and is mainly there so that the editor can offer the correct fields. However, the same could be achieved via DS Entity, which would make more sense and would also offer all other fields defined in DS (Lookup fields, Join entity fields, etc.) for selection.
It is also necessary to ensure backward compatibility.
This wouldn’t be practical, because you can use one screen section in several different screens and each screen can have a specific data structure. What you propose would mean that you would have to save an identical screen section under different names to have them properly bound to the screen and data structure they are based on.
When you create a screen, all the data included in it, in all the sections involved, should be in the underlying data structure of that screen, right? So what is the issue if the data must be in the DS anyway in case of all the screens where such section is used?
As @vikter noted, the screen section stores data members (entity fields) as text. So it does not matter much how you get them there. As long as the final data structure contains the same field names, you are safe.
On the other hand we have cases where you model multiple fields on the level of data structure (lookup fields, joined entity fields) and there you have no way to drag & drop them in the designer. You must manually type them in. It is confusing.
So I think it is a good idea to find a way how to model screen sections based on the actual data structure. On the other hand, having the old option (pure entity) still at hand might be beneficial.