...

You'll also notice that RPC, unlike document-style, treats web service calls as functions with parameters and return values. Whereas document-style just passes around documents for requests and responses, RPC passes around function name, parameters, and result. The operation name in the request is qualified by a namespace specified by the SOAP input body declaration in the WSDL as the namespace attribute. By convention, the operation name in the response will have the tag Response appended to it to show that it is indeed a response, and it also is qualified by a namespace, in this case the namespace attribute in the SOAPSOAP output body declaration. This is also known as the wrapper namespace, or the on-the-wire namespace, because it is only used when the SOAP message is being sent and received. After the SOAP message is parsed, that namespace is no longer relevant.

...

There is one more "axis" to consider when formatting and parsing a SOAP message: encoding. This is specified in the SOAP input and output body tags in the WSDLWSDL for each concrete operation in a binding. The use attribute is either set to literal to specify no encoding, or to encoded to specify that an encoding scheme will be used/expected to format the message. The only real encoding scheme being used is SOAP encoding. The SOAP encoding mainly allows for references and SOAP arrays, among some other lesser features. It also will generally add an attribute to specify the type for each of the elements, using the XSI (XML Schema for Instances) type tag.

...

• Document literal, when only one part is used and that part is an element, is fully WS-I compliant, meaning that document/literal/element is more common in real-world applications.
• It is more intuitive for those who see web services simply as passing XML documents back and forth (rather than as function calls).
• The message is pretty succinct and easy to parse.
• Less extraneous information means faster transmission and parse speeds.
• The Body's content is completely defined by the schema, so it can be completely validated from front to back.

Drawbacks

• Only element parts are compliant to the WS-I profile, which means their use is more common than typed parts.
• If document-style messages are used with more than one partone part, there is no standard way of formatting the SOAP for such a message.
• The operation name The operation name is not present in the SOAP message and must be sent as extra information (e.g. the “SOAPAction” header in HTTP).
• For those who view web services as function calls, this style doesn't make a lot of sense, since you aren't passing in "parameters" to a function.

Document/Encoded

Benefits

• None over document/literal.

...

• No one uses this style because it doesn't provide any benefits over document literal (encoding doesn't make sense for a standard XML document format).
• It is not WS-I compliant.

RPC/Literal

Benefits

• RPC-literal messages with parts defined as types are with parts defined as types are WS-I compliant.
• The operation name The operation name is included with the message, making dispatch easier.
• The procedures are parameterized with partswith parts, making the web service call essentially a "function" with parameters and a return value.
• There is no redundant type encoding redundant type encoding information.

Drawbacks

• SOAP with attachments or anything that uses HREFs aren't available without SOAP encoding.
• The messages are usually a bit longer because of the operationthe operation/part informationpart information.
• The messages cannot be fully validated because only the individual parts are individual parts are described by a schema. The number and name of the parts must the parts must rely on the WSDL to validate correctness.
• RPC-literal messages with parts defined as elements are not WS-I compliant.

RPC/Encoded

Benefits

• Encoding allows for SOAP arrays, references, etc.
• Encoding still has the main advantages of RPC (parameterized functions, operation name included, etc).
• The type encoding information is necessary for data graphs (i.e. hrefs) and derived types.

Drawbacks

• Type info will be included which is usually extraneous, confusing, and redundant.
• Using an encoding scheme is not WS-I compliant because all encodings are extensions.
• You still cannot validate the message from the Body, for the same reasons as in RPC-literal.

Document/Wrapped

Benefits

• WS-I compliant since it is essentially document-literal with one element part.
• Messages can be fully validated because the entire message is described by a schema. 
• Message can be easily seen as a function call with parameters, much like RPC.
• No encoded type information
• Operation response element is the operation name with Response appended the operation name with Response appended to it, thus matching the RPC style exactly.

Drawbacks

• The schema and WSDL get more complicated because the element name in the schema must match the operation name.
• Since an element must be defined that matches the operation, only one operation with this name is allowed. Normally you can have the same operation name in two port types and they'll be two different operations. But with doc-wrapped, the element has to match the operation and you can't overload that (not even by putting the element in a different namespace, since the local name is what counts).
• It is not an industry standard, although it is widely used. It came from Microsoft, but no one has taken up the flag and put the specification into words (so there are still some ambiguous edge cases).

Each of the above styles (except for document/encoded which is never used) are all common. Doc-wrapped is newer but it is definitely gaining ground in standard usage because it gains the benefits of RPC and can still be validated as a full document. RPC messages are useful when mapping web service calls to C++ or Java methods, because they can be overloaded with different parameters, and the parameters are pretty easy to match up to C++ and Java function arguments. Document-literal can be useful when passing full XML documents around to web service implementations that don't implement function calls (BPEL, HTTP servlets, etc.). It is also useful when you need overloaded functions but only have one parameter, or you don't want the extra overhead of the extra RPC elements.

References

WS-I Profile 1.2: http://www.ws-i.org/Profiles/BasicProfile-1.2.html

...