While the data and anecdotal experience certainly support that manual memory management is faster, I think focusing on that specifically misses the point a bit, because you don't just get performance by taking out the garbage collector.
For example, in systems programming memory is often not the only limited resource that needs to be cleaned up. In such situations, C++-style RAII is extremely valuable. While finalizers can be added to languages with garbage collectors, and indeed have been [1][2], it's not possible to predict when the resource destruction will occur, meaning that they end up requiring explicit (de)allocation of resources in pratice [3][4]. And if you still don't think it's a hard problem, take a look at some of the discussion the D community is currently engaged in over the same issue [5].
Another problem with GC that's already been brought up is the difficulty of using it in hard realtime systems. IBM has done a considerable amount of work in this area, including the development of a garbage collector designed specifically for realtime Java programming [6]. Some things to note about their solution include the heavy restrictions on the hard-realtime threads [7] (they are essentially disallowed from interacting with garbage collected objects, and in any case are not totally free of garbage collection), and that what are called realtime threads are still subject to nondeterministic pauses [8].
There are many more potential issues than this (e.g. signal handling [9]) but I hope you will agree that there is a clear need for languages without mandatory garbage collection. Given that such languages are necessary, it follows that it would be nice for there to be safe languages without mandatory garbage collection that can perform these tasks. While that doesn't necessarily mean you should care, it probably does, because even if you don't personally write programs with such requirements, you almost certainly use them.
[9] See, for example, Asynchronous Signals in Standard ML, http://www.smlnj.org/compiler-notes/90-tr-reppy.ps ; section 5.2 gives a good overview of why truly preemptive signal handling, often a necessary part of systems programming, is not in general possible in a system with garbage collection.
For example, in systems programming memory is often not the only limited resource that needs to be cleaned up. In such situations, C++-style RAII is extremely valuable. While finalizers can be added to languages with garbage collectors, and indeed have been [1][2], it's not possible to predict when the resource destruction will occur, meaning that they end up requiring explicit (de)allocation of resources in pratice [3][4]. And if you still don't think it's a hard problem, take a look at some of the discussion the D community is currently engaged in over the same issue [5].
Another problem with GC that's already been brought up is the difficulty of using it in hard realtime systems. IBM has done a considerable amount of work in this area, including the development of a garbage collector designed specifically for realtime Java programming [6]. Some things to note about their solution include the heavy restrictions on the hard-realtime threads [7] (they are essentially disallowed from interacting with garbage collected objects, and in any case are not totally free of garbage collection), and that what are called realtime threads are still subject to nondeterministic pauses [8].
There are many more potential issues than this (e.g. signal handling [9]) but I hope you will agree that there is a clear need for languages without mandatory garbage collection. Given that such languages are necessary, it follows that it would be nice for there to be safe languages without mandatory garbage collection that can perform these tasks. While that doesn't necessarily mean you should care, it probably does, because even if you don't personally write programs with such requirements, you almost certainly use them.
[1] C# Destructors, http://msdn.microsoft.com/en-us/library/66x5fx1b.aspx
[2] Java's Object#finalize, http://docs.oracle.com/javase/8/docs/api/java/lang/Object.ht...
[3] .NET's IDisposable (often used with using), http://msdn.microsoft.com/en-us/library/system.idisposable.a... ; see also c# - Proper use of the IDisposable interface, http://stackoverflow.com/questions/538060/proper-use-of-the-...
[4] Java's AutoCloseable (designed for use with try-with-finally), http://docs.oracle.com/javase/8/docs/api/java/lang/AutoClose...
[5] A few considerations on garbage collection, http://forum.dlang.org/thread/ljr549$1kti$1@digitalmars.com ; More radical ideas about GC and reference counting, http://forum.dlang.org/thread/ljrm0d$28vf$1@digitalmars.com ; GC vs Resource Management, http://forum.dlang.org/thread/hhpldnysndikzbkfbiqm@forum.dla...
[6] Introduction to the Metronome Garbage Collector, http://publib.boulder.ibm.com/infocenter/realtime/v1r0/index... ; Real-time Java, part 4: Real-time garbage collection, http://www.ibm.com/developerworks/library/j-rtj4/
[7] Using no-heap real-time threads, http://publib.boulder.ibm.com/infocenter/realtime/v1r0/topic... ; in particular, Constraints on Java threads when running with NHRTs, http://publib.boulder.ibm.com/infocenter/realtime/v1r0/topic....
[8] Metronome Garbage Collector limitations, http://publib.boulder.ibm.com/infocenter/realtime/v1r0/topic... ; Metronome behavior in out of memory conditions, http://publib.boulder.ibm.com/infocenter/realtime/v1r0/topic...
[9] See, for example, Asynchronous Signals in Standard ML, http://www.smlnj.org/compiler-notes/90-tr-reppy.ps ; section 5.2 gives a good overview of why truly preemptive signal handling, often a necessary part of systems programming, is not in general possible in a system with garbage collection.