Hi Sumit,
the other postings already describe most of the technical issues, I'd like to add some design considerations because you've ask for scenarios.
The original purpose of stub areas was to save router resources, especially memory. Although hardware capabilities have improved considerably since the 90s, this still applies to today's networks.
Imaginge the redistribution of a large amount of BGP routes into your OSPF Backbone Area.
If you had to interconnect a small site with only a few low-end routers, you possibly couldn't enable OSPF here until you replace the routers with more powerful ones.
If you have an area (e.g. the small site mentioned in the example above) which has only one single exit point, that's like leaving a dead-end street: You don't need to have detailed information about all the possible destinations at this point, knowning the direction to leave it is sufficient. This scenario correspondes to a totally stub area: A default route will be injected replacing the detailed information about the outside world and that's it. Minimal consumption of router memory, CPU and bandwidth.
If you have more than one exit point, the use of a totally stub area could lead to suboptimal or undesired forwarding paths. By using a "normal" stub area instead you can achieve a better path selection at least for inter area destinations, external destinations will still be replaced by default routes. Of course this consumes some more resources but you're still rid of all the external prefixes.
A NSSA adds the possibilty of distributing the prefixes of a small external routing domain (e.g. a RIP cloud or some static routes) into the rest of the OSPF domain.
Also form a design perspective the injection of a default route by stub areas can be something very welcome, e.g. when you're using static default-routes in the backbone area but can't inject them into OSPF for some reason.
If you need to use an area for a virtual link, you can't configure it as a stub area.
Hope that helps
Rolf
