It isn't always easy to get a handle on what the SDK is, and is not, for. Here's an attempt to clarify it.
The Acrobat SDK: as its name suggests, this is something to help developers write solutions that use Acrobat. It is not a way to create solutions that are an alternative to buying Acrobat. The Acrobat SDK also includes some features that can be used with Adobe Reader. Since Adobe Reader is free, these features are very much more limited. The SDK is mainly documentation for developers, now in HTML format. There is a little sample code, but this only helps to understand the SDK; developers who hope to find sample code for their problem to use with a little hacking are usually disappointed.
Plug-ins: the largest and most powerful part of the SDK is used to create plug-ins for Acrobat. This is an enormous API covering many aspects of PDF reading, editing and display. It can be time consuming to learn, and a knowledge of the PDF file format (ISO 32000-1, included with the SDK) is helpful to understand its philosophy. Plug-ins are always written in C/C++ using particular compilers; this limitation is needed because plug-ins load as part of Acrobat. Plug-ins are not separate programs, but can be run by the user of Acrobat e.g. via a menu or button click. Plug-ins can handle events like the need to paint an annotation to screen. Plug-ins can be written for Adobe Reader, but there are many limitations and a special license is needed.
Interapplication communication (IAC): the most often used part of the SDK is used to automate Acrobat from external programs. This has many limitations, and it's important not to assume any kind of solution is possible before detailed study of the SDK. The main IAC API hasn't been changed in over 10 years and is very limited (but still useful). This uses OLE (Windows) or AppleScript (Mac OS X). For example, this can delete pages, or open a primitive PDF viewer in your own application. This is supplemented by other APIs, such as the Forms API for working with forms (but not Designer forms). The most powerful tool for automating Acrobat from another app is Acrobat JavaScript; you can use IAC to run JavaScript. Beware of security limitations which often stop developers from doing things which seem quite reasonable. Interapplication doesn't have tools for low level editing of the objects on PDF pages, but content can be added as form fields or annotations (which is not always an acceptable substitute).
Suitability, server use: The Acrobat SDK, since it uses Acrobat, is subject to the technical and license limitations of Acrobat. For instance, it only supports a single instance and thread, and has to have a logged in window to display in. It is not suitable for heavy duty automation, Acrobat is an end user tool. In addition, Acrobat is not generally suitable for use on a server, both because there is no monitor and because the license is usually held to forbid it except in very strict situations (legal advice may be needed).
PDFL: Adobe has a second PDF developer product, PDFL, often licensed through DataLogics. This is similar enough to the plug-in API that some applications can be converted simply between the two, but it doesn't include the viewing components of Acrobat. This is used to create standalone applications that don't use or need Acrobat, and might be used on a server. PDFL is a C/C++ library but DataLogics provide wrappers for certain other languages. Licensing costs are significant and individually negotiated (the process can be time consuming). It is also available for some Linux and Unix systems.
A more detailed introduction and Adobe's own words can be found in the SDK itself, which has introductory sections as well as references.
