Typically, you're right - GC internals aren't usually relevant. That is, until you're fire-fighting a GC-related issue in production. GC internals aren't something you want do a crash-course on while your app burns.
I'd call it a good sign if you can even identify GC-related issues in production. That means all of the other problems that seem to plague .NET shops have been taken care of.
It's always a captivating read for me! I find most discussions about the tradeoffs of GC vs reference counting versus manual memory management are loaded with bias.
There’s definitely more there than most .NET devs need to know, but I personally have found learning more about the GC to be incredibly relevant in my day to day work. I would have said the same thing a year ago, now I feel differently, but that is of course heavily inflected by my personal experience.
Similarly you might not expect that reading CLR via C# would make you a better programmer at a high level with things like DI and big frameworks and everything, but it makes you see what you're writing in an entirely different light. A whole other layer below the surface.
I would strongly second that endorsement. I would love a new edition taking the CoreCLR more into account but it’s still more relevant than most any other book I can think of.
