Strategies for long term data growth optimization for a query with an index on a joined table
It is not inevitable that it will keep using the seq scan.  Perhaps at some point it will change (indeed, if the tables are vacuumed and analyzed, I don't get the seq scan in the first place, as the anonymous horse indicates.)
However, if your tables keep growing into the future (rather than into the past) your query will count more and more rows, and this will take longer and longer to do.
Since you are using fake data anyway, why not just use more of it and see what happens?  This is the key benefit of working with simulated data sets, you can simulate whatever you want.
With 9.6, I get a nested loop over two index scans as long as the exchange_content table is well-vacuumed enough that the index-only scan seems worthwhile.  So I would say that the main strategy you have overlooked is to design your indexes so that you can get index-only scans, and make sure to vacuum often enough. For insert only/mostly tables, it can be hard to get autovac to vacuum often enough, (until v13 introduces autovacuum_vacuum_insert_scale_factor) and so until then it might be best accomplished by &quot;manually&quot; VACUUMing from cron jobs.
Moving the created_at column to the other table would be an obvious winner if you were using an inner join rather than left join (at which point, you could drop the join with exchange altogether and just query exchange_content). But if the left join is really needed, it is not clear how this could work. Also, assuming that exchange_content is not where the column naturally belongs, then moving/copying it there would be a denormalization.  This generally comes at a high cost from a integrity and maintenance perspective even if it does pay off for SELECT performance.
It is not clear how partitioning could help here.  You can't partition exchange_content by created_at without having the created_at column exist in that table.  And if it did exist in that table, you wouldn't need partitioning you could just index it directly.