Why so many logical reads?

Those are page reads, mind you. That is relevant.

Possibilities:

• Improper or insufficient indexing. Are any of the filtered fields indexed? How wide are the indexes (see below)?
• Poor page density. What's your fill factor on any indexes you may have? If it's too low, you are pulling a lot of pages for this.
• Very wide indexes. If you have indexes but they have a lot of fields, or very wide fields, then you get less rows per page.

I'm guessing you have a table or clustered index scan happening for at least one of these criteria, and the table is wide-ish which causes a lot of data to be read, regardless of how much data you actually need.

Because you don't have appropriate indexes. Most importantly you would need an index on TABLEX (ORDER_ID) and an index on TABLEX_RESULTS (ID). Preferably the index on ORDER_ID should include (DAYS, ID, RESULT_DATE).

You have an index on ORDER_ID, but is not covering. For the tables_results, either you don't have any index, or your comment does not include them.

There are a large number of reads because SQL Server is scanning the table to execute your query, which requires reading every row.

You can reduce the number of reads by creating narrow indexes that contain only the columns needed by the query.

You might also consider caching the results of the query, to possibly avoid having to run it more times that you really need. You could cache in memory, or perhaps in a small table.

Another option is to periodically move your data into an Analysis Services cube, and use ADOMD.NET and MDX to query it -- should be much faster than running large aggregation type queries in the relational engine.