I tend to take the position that arguments about the merits of GCs are proxies for a different issue at a higher level of abstraction that is rarely tackled directly. One of the correctly argued advantages of GC is that it automatically handles some difficult edge cases like ambiguous lifetimes and cyclical references. In my opinion, there is an interesting discussion to be had around why these edge cases need to be solved in real software systems.

At least in my experience, the cases that GCs solve uniquely well are a code/architecture smell. Every time I've written some complex code that creates the edge cases GCs solve well, it has been a red flag for poor design. I've never run into one of these cases where there was not a different, better design that made these edge cases go away in a sensible manner. In a sense, GCs primarily help developers by allowing them to ignore issues of poor design (which may not be their fault) in order to get things done. While there are obvious merits to the "just get things done" view, the reality is that the sloppy design that leads to these kinds of situations tend to be strongly correlated with other software problems that a GC won't paper over.

Programming languages strive to enable and encourage good design with their feature set. There is an interesting philosophical debate about language features that exist almost solely to mitigate the effects of poor design, which IMHO is where GCs fit. Does availability lead to enablement in practice?