Fully-exposed APIs

As a developer, I've always preferred working with platforms that have fully-exposed APIs (Application Programming Interface). In the past, I've needed to use software with no APIs at all, exposed, well documented APIs, and everything in between. Although there are always (messy, complicated) ways of integrating with other types of software, there's no question that being able to call into platforms through native APIs is preferable.
In the .Net world, using reflection is a great way of calling components even if the API isn't exposed. I've used Lutz Roeders reflector numerous times to peak inside .Net assemblies to find what I can call, and sometimes for hints on how the business logic itself operates.
A particularly good API I've used is the K2 workflow's. K2 is a sophisticated workflow engine that allows seamless integration into .Net applications through it's well-documented API.
The Google maps API is another good example; The number and quality of the Google maps mashups on the web is testament to its usability.
As for the reasons a company may expose the API, the benefits are numerous. Developers like myself will always lean toward using software with exposed (and well documented) APIs. We'll buy the software ourselves or influence our superiors to make the purchase for our group. We'll learn the platform inside-out, and write code to integrate our own software. Once we're integrated, it's much harder to switch to something else, so the company has a captive audience.
Companies may not expose their APIs for valid reasons as well. Some companies licence control to their APIs to generate revenue and to have a greater say about how the software will be used. Plus, APIs can be expensive to develop. Some companies don't intend their software to be integrated in this manner; I've recently had to depend on software that could only be controlled through the UI.
If you're a developer that has the opportunity to design an API, google has a great keynote called How to Design a Good API and Why it Matters. It makes some great points on developing an API and documenting it, and provides some tips on SPIs (Service Provider Interfaces) and why names matter ("API is a Little Language").
APIs are a great way of integrating software at the application level. However, as always, it's better to abstract services with SOA once applications require integration.