+1 for readability generally.

My understanding of the performance differences are that string concatenation of two elements is marginally faster than using an f-string, but if an f-string includes 3 or more variables then it performs better.

a = "A"
b = "B"

c = a + b  # Faster
c = f"{a}{b}"

d = a + b + c
d = f"{a}{b}{c}" # Faster

Overall I think the performance difference is so small it doesn't really matter.

I don't see any changes to linting rules. Was this done by a tool or manually?

My primary concern with PRs like this is being friendly to novice users. Generally using modern conventions like f-strings is a novice-friendly thing to do (especially compared to older format strings conventions that are less common). That being said if I'm being completely honest I'm not sure that replacing things like a = "foo-" + b + "-bar" with a = f"foo-{b}-bar" really adds much value for anyone. The performance difference in negligible and IMHO the readability is the same. You spent a bunch of time doing it, I've spent a bunch of time reviewing it, and the project isn't really any different as a result. Given that you've done the work I'm happy to merge it, but I would caution that PRs like this might not be the best use of time for any of us.

It's also possible to write ninja f-strings which border on being unreadable, especially for novice contributors. I don't see any of those in this PR, but I would reject a PR that had them in and favour something more traditional and readable.

Overall I'm +1 on things that linters can catch and fix themselves. With regards to FLY002 (and any other rule for that matter) if a novice user tries to commit something and pre-commit is always shouting at them and they have to fix it themselves that increases the friction to contribute, so I wouldn't be supportive. But if pre-commit runs and auto-fixes a bunch of stuff then I'm totally onboard with that. It sounds like FLY002 can always be auto-fixed so feel free to open a PR to add it.