Hi Frans
I can tell that you do not want to modify the query generation for Entity framework, however I am unsure why you are so concerned about the proposed modifications.
When testing often its important to test beyond the scope of normal operation. Such testing especially in performance scenarios outlines and exaggerates potential bottlenecks and Big O issues.
If it would perhaps seem more reasonable for you to conciser a much smaller amount of latency and fewer rows I would encourage you to read my results and examine the differences at a mere 5ms RTT and 100 rows.
I think it would also be really important for you to note that EF is a batch based transactional system by design. This means that Inserts updates and deletes are all processed at the same time when you call SaveChanges. While in other frameworks (which from my experience mostly transmit to SQL on the spot and then commit on save) there is less option to reduce latency by aggregating statements EF is somewhat uniquely in a position to do this.
As a bit of a footnote i would like to challenge your assumption that ORMs shouldn't be used in bulk scenarios. Often performance is not the only factor for such scenarios, Entity framework provides a number of benefits around readability and simplicity of code over and above simply allowing you to write to a database. In addition I feel that there is value in being able to use a single ORM across your whole application even if a section of that application involves some kind of bulk operation. Because of these reasons developers are often willing to take a performance hit (as long as it isn't too large) to provide a more maintainable system.
As an example of this just last week I was asked if there was any way for someone to use EF to do a 1,000,000 row recalculation operation. While you may feel that this is the job of a bulk tool the particular individual who asked this had found that using a bulk tool for this (while giving performance gains) substantially increased the maintenance costs on the application, in addition the code was harder to follow and had to have additional transformation logic. This recalculation was a small component of the application as a whole which used successfully used EF for the remainder of the code. In this particular scenario the developer was willing to sacrifice some performance for some application simplicity (and this isn't the only case like this I've heard).
I hope this helps you understand why examining options for query improvement has some really great potential gains for Entity Framework. I think everyone here is interested in getting the very best results possible and would not be interested in such improvement if they felt they were not warranted or sensible.
Regards
Luke McGregor