What are the possible performance implications of dropping a not used ‘surrogate key’ column?
I have a very large (>10m rows) 


Tables with billions of rows in them are common — don't fixate on the size of the table, it is much more important to know how many blocks you scan to query it, which depends on the query and on indexes. You do not want to consider partitioning, or anything exotic, just because you have 10 million rows in a table.


  I essentially run two different types of queries on this table:
  
  
  "Give me all of the measurements between time start and time end of _reading_type 0 for meter_id X", or
  "Give me all of the measurements between time start and time end of _reading_type 0 for facility_id X" (I believe the facility_id
  column denormalizes the table, but saves what was an expensive join).
  


Then your indexes would be better off as:

"ix_measurement_timestamp_meter_id__reading_type" btree (_reading_type, meter_id, "timestamp")
"ix_measurement_timestamp_facility_id__reading_type" btree (_reading_type, facility_id, "timestamp")


… or better still make them partial indexes where _reading_type=0:

create index on measurement(meter_id,"timestamp") where _reading_type=0;


Calling a column "timestamp" is not a good idea, change it if you can.


  I am considering dropping the id column, which is a meaningless ‘surrogate key’, as I never, ever query it, but I'm curious what the performance implications would be. 


Any impact on performance is going to be minimal compared to tailoring your indexes to make them more selective.