Very good questions as I had similar questions in my mind sometime back.
1.) Most examples I have seen use factory classes to create almost every concrete class in the system. Is there ever a time where you don't need a factory to create a class or it is not a good idea?
Well this is a good design
philosophy, which you will see in most systems being built. This is a pattern which a) separates the construction of being scattered across multiple places in code
b)sometimes an appropriate class is instantiated and cast to an interface and returned. (combination of Factory and a Manager). This way client code is shielded with nitty-gritty details and is simply a nice layer to your application. So if you have a code change you have only one place.
2.) Same as the factory classes, most examples I have seen create an interface class for every concrete class in the system. Is there ever a time where this is not needed or not a good idea?
pretty much as explained above.
3.) The Factory and Abstract Factory patterns seem to require that concrete classes inherit from an abstract base class. Is this is a hard requirement or will implementing an interface instead of extending the abstract class abide by the pattern rules as well?
no hard and fast rules as such....Abstract Factories are not typically used all that often in fact. I personally like implementing an interface (u can implement multiple interfaces
...not stuck with one.....