I think it's reasonable to have a warnings-are-errors approach even in medium sized teams, or if not quite that approach perhaps a "warnings go in the bug tracker" approach.
I'm far from a Swift expert, but I usually found I could reduce the compilation time with ~10 mins of work. When I turned these on for a small codebase (60k lines, ~50% of an engineer split across 3 people), it only took a few hours to solve all the instances of this, and they were mostly obvious cases where a 100 line function could be split into 3 and solve the issue.
Warnings-as-errors is a great policy in general, but these are non-deterministic warnings based on compile time wall timing. Coworker working on a slower computer than you? He can run into hundreds of errors after a pull that you introduced but couldn't see, what now? Running something intensive in the background? You can't compile successfully any more. Not ideal.
That's true, but a setting of 100ms is a few orders of magnitude higher than expressions should be so it's quite possible to make this fairly reliable.
The problem is that if this ever catches anything, then there's things that it almost catches. And you have no way of telling if you have something expression that takes 99 ms on your machine, so will take 101 ms on your coworkers'. The appropriate way to deal with this in general is to have separate warning and error thresholds, where the difference between the two is greater than the variance between machines, e.g. 50 ms and 100 ms; at least in this case when your coworker checks out a broken build he can see that warnings were introduced in your commit in a CI build log and track it down to the source.
It's easy to have one setting for local development and one for CI. Xcode supports different profiles natively so you can just put 50ms or whatever in your user settings and leave 100ms or even 1s in your standard build settings.
Also, this sort of works the other way too. Just because something failed at the 100ms threshold doesn't mean it would complete in 101ms, it might take 500ms, 10 minutes, or be undecidable, and it's important to fail CI in those sorts of cases to protect other developers from issues, so having a limit is useful even if it's relatively high for the default case.
I guess I don't see what the actual workflow is supposed to be for a new team member who joins (potentially with a different computer than everyone else), checks out the code, and has dozens of errors when they first try to build.
I'm a huge fan of error'ing on warnings, but I really don't see it as appropriate for nondeterministic cases.
I'm far from a Swift expert, but I usually found I could reduce the compilation time with ~10 mins of work. When I turned these on for a small codebase (60k lines, ~50% of an engineer split across 3 people), it only took a few hours to solve all the instances of this, and they were mostly obvious cases where a 100 line function could be split into 3 and solve the issue.