It's not really odd at all, in fact.
The key thing to note here is: your add operator overload is overloading a type for which the fields are themselves generic (as in, "unknown until specialized.") So it works, because there is no specific underlying implementation of "+", of course.
The math functions such as Abs, Sqr, Sqrt, Sin, and so on are however not generic in any way. They take specific, named types (as they should, of course.) So the compilation fails, because "T" is not a single, or an Int64, or anything else at all. It's literally nothing at that time.
It is true, though, that FPC is a bit inconsistent in how it handles generics. It is as far as I'm aware not supposed to care about the validity of generics *at all* until they're specialized, but it does, which introduces some limitations such as what you've encountered here.
So not necessarily a bug if you ask me, but at the very least a specific flaw in the current implementation of generics. Perhaps Sven might be able to weigh in with their opinion on this?
On a related note: Remember to always, always, always, specify that record parameters are either "const" or "var" in methods (in 99% of cases.) Circumstances where you ever actually want to have a "bare", unprefixed record parameter are extremely rare. Also simple math methods like what you're doing there should generally be marked as inline (as FPC will not inline them, ever, otherwise.)
(And yes, all of that stuff does specifically matter, folks. There are very specific, known things that FPC simply won't do, and isn't supposed to, with regards to optimization unless you tell it to.)