If we start by assuming the developer is a "good dev", I can't imagine Copilot is going to do anything useful for them, as this isn't going to be a useful way for them to come to understand how the system they are using works, and it won't support them building abstractions to reduce boilerplate. This tool is simply not useful for them.
Which leaves us with the idea what Copilot is a tool designed for "bad devs" to be able to do less work to do the bad things they do, and while I sort of appreciate the idea of "it is worthwhile to support people who don't know what they are doing in their attempt to do the bad thing they are doing anyway", I have severe reservations about doing that with engineering... it at least needs to be marketed as that!
Otherwise, the two main things we should be doing for "bad devs" is either helping them become "good devs"--which this doesn't do for much the same reasons it isn't useful for "good devs"--or we should honestly be trying to convince them not to be a developer at this level at all (which might include building higher-abstraction systems that are easier to use and understand).
There's also a large difference in scope between the kind of suggestions a linter gives and what copilot does. Linter usually works around the syntax for equivalent semantics, while copilot tries to infer semantics.
The fact that there are so many people that like them that all the IDEs have the feature on by default with the off switches scattered all over their configuration so you can't turn them off is scary.
The problem exhibited in TFA is not so different from people copy/pasting StackOverflow answers without understanding them.