>>22
Regarding faster hardware, that is completely the wrong attitude, IMHO. Just because hardware gets faster does not mean programmers should not care about performance of their software (especially in regards to time and space _complexity_ rather than cpu _time_).
>>23
It's not what garbage collection allows you to do (it allows you to not worry about memory allocation and deallocation), but rather that manual memory management becomes difficult as software grows to the point that garbage collection yields better performance and fewer risks (if you manually manage memory, if you fuck up, you got a memory leak). Also garbage collection aids ease of development because manual garbage collection takes effort.
Manual garbage collection can, obviously, yield better performance, because you can micromanage when allocation and deallocation happens and whatnot (ie, you have more control), HOWEVER, these days garbage collectors are advanced enough that this is difficult to achieve nowadays (just like hand optimized assembly code is rarely more efficient than compiler optimized code these days).