EntityFieldQuery has proven quite adequate in my time with Drupal.
I've even heard of people that don't use a debugger (such as XDebug) and that echo or print have proven adequate for their projects - no ofense - I'm just trying to say it depends on the type of project.
The problem with the EFQ is that it is mainly designed to query 1 entity and its fields and does not manage complex relationships between entities (in D8 FieldQuery it got join support), nor it allows to retrieve specific property or field values from the entity itself or from any of the related entities. To add up, writing complex conditions (multiple nested ands/ors) is not "easy". So EFQ is really only usable on simple scenarios and is more than sufficient for regular websites.
There has been some work on that though, such as the EntityFieldQueryExtra but still far from being a complete solution.
As you say it doesn't look very sane to have all this technology mixture (like it is not quite sane either to use Drupal for complex applications). We are already integrating .Net to offload things from PHP so that mix is already stable and natural to us, and here we are trying to push the integration a bit further because at the moment we are offloading very isolated functionality.
The discussion is not what you can or cannot do with one approach or the other. On the Drupal side you could write your plain SQL statement and be happy querying and retrievig whatever you want, in the same way you can be happy without a debugger, without QA, without error logging, etc.
The point is productivity, maintainability and overal quality. We don't use PHP or Drupal for the really big projects, but I cannot imagine and would not consider for a really "serious" project anything that was not strong typed, with autocomplete and had compile time query validation. Having a data layer with autcomplete, design time query validation and reusable expressions such as LINQ reduce development and maintenance efforts as much as 10%. Now take a team of 20 people working on the same project full time and on an ongoing basis and that 10% is a big load of money. Reusable expressions make the data layer more robust, newcomers quickly see what the whole data model is like while typing, query errors are completely removed from the equation. And its not just about money, but developer sanity and project quality. None of this will make any sense if in your projects you have 50 or maybe 100 custom crafted queries.
[...] practically I really don't see the point
I haven't seen yet a "big-complex" php project where they were not offloading stuff into C, C++ or Java (because of the slowness and shortcomings of PHP) and the strambotic ways they were using to integrate them - even at a per request basis and using command line approaches (proc_open). Lack of proper threading, slowness, etc. are reasons to move workload to other technology/stacks. Having said that, using COM to interact with .Net binaries is a much more smooth and integrated approach than other things I've seen.
[...] how slow and tedious .NET development is
I don't want to go into the .Net vs PHP argument because, besides not even being the same thing and so cannot be compared (are you comparing the language, the ecosystem, the frameworks, the development tools?) you can have fun for hours browsing the internet reading about it and not finding a single serious and properly argumented analysis of it. Some of our software projects have more than 300,000 LOC writen from scratch and something between 4,000 and 6,000 custom queries and I cannot imagine them being done in anything else than .Net and with the amazing development and maintenance costs the productivity oriented .Net ecosystem gives us.
When the weight of the paperwork equals the weight of the aircraft, the plane is ready to fly.
- standard Boeing engineering rule
I just quoted this because in mission critical or big serious projects, it's not just about getting the thing to work. It's about doing it the best way possible.