F1 is technically releasing the data, but not explicitly for the purpose of building telemetry analysis tool. They're just made available for use on their own services (such as F1TV).
The real source of the data is the livetiming service F1 has developed. What happens in that service internally, we don't really know (as far as I am aware), but the data that we use to display telemetry comes from the livetiming endpoint :
Now technically speaking, this data is supposed to be available to those who have a livetiming subscription through F1, but it was unprotected for a long time. Recently they changed it so that you cannot fetch live data (as in while a session is ongoing), but the /static/ endpoint is still free to use and that's where the data is coming from. People who have developed these telemetry services (like me) and made them public are technically in F1's hands. At the moment, we are not fetching data that F1 makes public anywhere else in any of their services. But if F1 decides to write their own Telemetry Analysis platforms at some point (for money), then we all will be forced to shut the public things down.
For the time being though, it's available for use. You can try it yourself (here is the [compressed] telemetry data of the 2023 Bahrain Grand Prix Race for example) :
https://livetiming.formula1.com/static/ ... jsonStream
What FastF1 (and other libraries) do, is that they get this compressed data, process it, and make it available to use on easy-to-work-with data structures.
FastF1 is a really well-developed and extensive API, and there's a lot going there, but their api service specifically (the one responsible for fetching the data),
can be checked here
So what is the data exactly? In short, it is what F1 uses to display the HUD on F1TV or on their web livetiming service and it is actually coming directly from the transponders in the cars. This means that data quality-wise, this is definitely not some mumbo-jumbo useless crap, but unfortunately it's prone to errors and inconsistencies (I guess people can kind of tell considering how often TV graphics glitch out). The data is often sampled at different frequencies on different laps, recording of data often starts missaligned for different laps. There can be data corruption during specific point in the lap. DateTime on specific sample points may be off and many more possible issues ...
Some of those issues, FastF1 deals with internally. Others are a little bit harder to deal with. F1Tempo (as far as I am aware), uses FastF1 functions out of the box, so the telemetry there can vary a lot lap to lap. The new one (GPTempo), seems to do some processing before displaying it to the user so it's better than their old site. If you prefer their interface, I would recommend using GPTempo instead of F1Tempo.
As for me personally, I also do a lot of post-processing to the data that comes from FastF1 and you will notice in F1InsightsHub there's rarely weird delta spikes in the braking zones and whatnot. Also, I try to perform alignment so that sector gates match exactly to the driven laps. Quality of alignment of course depends a lot on the quality of the original data, so that's why I put in the Delta Confidence to let people know when source quality was bad and I had to extrapolate to perform the alignment.