How is this advantageous over str.format?

f-strings (and str.format, and so on) are for producing strings directly; whoever writes the f-string or the call to str.format (say, Alice) takes responsibility for making sure every substitution is formatted (e.g. escaped) correctly. And Alice has to remember to escape every single substitution individually. There is a wealth of experience now on SQL injections, JS injections, and the like, which all ultimately result from Alice forgetting to call an escape function, or forgetting to sanitise, or misunderstanding which mechanism should be used where, or not knowing about other solutions such as parameterised SQL queries.

t-strings on the other hand are a tool that is designed to work in conjunction with library code. Someone - Bob - writes a library - LibFoo - for producing perfectly escaped HTML, or perfectly escaped SQL, or whatnot. Alice then imports LibFoo, and writes a call to it, passing a t-string with some substitutions. If an f-string, or str.format was used, then LibFoo only gets the fully formatted output string, and when it sees syntax, it can't tell whether Alice intended that to be treated as syntax, or whether it was in some user-supplied input that Alice fed to it via a substitution. But with a t-string, LibFoo knows exactly which parts were written by Alice and intended to be treated as syntax, and which parts were passed in via substitutions: it can then escape the substituted values (in the case of SQL, it can either escape them, or pull them out entirely and turn the whole thing into a parameterised query).

There's a couple of other advantages too. First, it's possible to write a t-string once and then pass it to several different library functions. Each function could do something different with it; with an f-string, that's simply not possible (you'd have to write the f-string repeatedly). One use case for this is in logging SQL queries: say you make a tool that needs to a) execute parameterised queries in a real database, and b) log the same queries for debugging, with parameters filled in in-place for human reading. Without t-strings, there are certainly ways to achieve this, but they're not simple nor do they produce particularly readable code.

Second, it becomes possible for code assist tools to detect the language that's actually being used inside the t-string. This means that if you write some HTML inside a t-string, and pass it to a function that declares (via typing) that it will process the t-string as HTML, syntax highlighting for HTML can be applied to the code inside the t-string, rather than it just being all one color; the same would work for any other language. If in future regular expressions move to using t-strings, this'll be immensely helpful: currently, some editors just basically hard-code raw strings (`r"..."`) to be rendered with regex highlighting, which is useful when you're writing a regex, but is annoying when you're using a raw string for any other reason.

I think t-strings are best seen as a way to embed any other language within Python code - without Python needing to know anything about that language. IMO, it's an incredibly powerful tool that every language should have, and yet I've never previously come across one that does, which is why I was so excited to see this PEP appear. You can put CSS and JS inside HTML, yes, but HTML, and editors and tools that work with it, are all specifically designed to support this - and then it's a similar argument for the case of putting HTML/CSS/JS inside PHP. None of these are generic - but t-strings are.