This is a great question, but a tricky one -- the answer is really straightforward for folks who've been doing Agile for a while, but fairly nuanced for teams who haven't.
The main characteristics of Waterfall projects that contrast them with Agile development approaches are that they are big-bang projects: They usually have stage gates for advancing from one stage of the process to the next (e.g., requirements, then development, then testing), and the functional teams tend to have a throw-it-over-the-wall approach to co-working.
Agile teams deliver smaller, cohesive "chunks" of product in short iterations. A common model is the Scrum approach, delivering in two-week iterations. This compression of delivery cycles has a set of defining characteristics, including creating assets and making decisions at the last responsible moment; collaborating, reworking and reprioritizing; and automating mechanical process steps (e.g., regression testing to assure that new code does not break existing functionality).
A product release includes multiple items created by the team -- broadly including the introduction of new capabilities and functionality, and improvements in quality and performance. They are packaged together into market releases of items that should be released together. An Agile team may create items through multiple iterations that are not available to customers until the next release. In enterprise software, for example, semiannual releases are common. Items created during a two-week sprint may lie fallow for months before a customer can benefit from them. Continuous development is an approach by which those items can be made immediately available to users.
A semiannual product release may include 100 items; a two-week iteration may include a dozen. What if you could release individual items as they are created?
Consider a bug that is resolved with a piece of software in the first week after a software release. An Agile team would have fixed that bug first only if it had been the most important thing they could be doing. It would be illogical for that bug-fix to sit around unused for months, waiting for the next release, if it could be released immediately after the fix was implemented. Continuous development is the way you make it possible to release items immediately as soon as possible. So, why doesn't every team do this? Why haven't they always done it?
There are two barriers -- one of software engineering, and the other of product positioning. There are risk and cost associated with releasing product updates. If your team moves -- without changing anything -- from semiannual to biweekly to continuous releases, the costs and risks associated with your release process would increase a hundred-fold. Automated regression testing, build processes and build-process regression testing are the keys to mitigating these risks and minimizing these costs. Only when the cost of releasing is trivialized can a team reasonably consider having hundreds of releases per year.
This works great for items that are independently valuable and releasable -- bug fixes are a great example. The concept becomes more challenging when items are not independent. A feature (imagine blog publishing software) to allow a user to upload an avatar for their profile will make sense only if there is also the ability to display their avatar next to their comments in a discussion thread. Both features could be developed and released independently, but they require each other to be released in order to provide value. Trivial examples like this one can be addressed by releasing them as they are developed, but in such a way that they are disabled or hidden until all of the needed items have been released.
From a positioning perspective, it can be important for a product release to have critical mass around which marketing collateral can be created. Consider mobile operating systems in the news today -- each new release represents a collection of capabilities being delivered together, in order to create a big splash in the market and stimulate demand. With continuous delivery, you lose the splash, in exchange for the steady and frequent improvements.
At the end of the day, continuous development is something a team has to invest in before it becomes possible. Given the nature of the market for a team's product, adopting continuous development practices may or may not make the product more successful.