Timescale works by creating a 'hypertable', which is an aggregate of a lot of smaller 'chunk' tables. These chunk tables are automatically split by date or incrementing id. This means that for queries that specify IDs or a date range within a certain range, you only have to query results within a few chunks, instead of looking through all the contents of the entire 'hypertable.' [1]
Timescale also offers some other things like compression which can save you up to ~96% disk space while also improving query performance in some cases. [2][3]
It also has something they call 'continuous aggregates' [4], which are similar to postgresql's materialized views, but do not require manual refreshing - they instead update periodically through an automatic background job. There is also a feature which builds on this called 'realtime aggregates' that allows you to combine the data within a continuous aggregate with the raw data in the tables that has yet to be materialized.
There are a lot more things besides that, but I think that's a decent overview of the major features it brings to the table. From a dev perspective these things all make the data and the database easier to work with (especially targeting timeseries data). There is an api reference [5] that has some of the other commands timescale adds, if you want to see some of the other things it can help you do.
[1] https://docs.timescale.com/latest/using-timescaledb/hypertab... [2] https://docs.timescale.com/latest/using-timescaledb/compress... [3] https://blog.timescale.com/blog/building-columnar-compressio... [4] https://docs.timescale.com/latest/using-timescaledb/continuo... [5] https://docs.timescale.com/latest/api