The approach taken by DKIM differs from previous approaches to
message signing (e.g. S/MIME, OpenPGP) in that:
* the message signature is written to the message header fields so
that neither human recipients nor existing MUA software
are confused
by signature-related content appearing in the message body
* there is no dependency on public and private key pairs
being issued
by well-known, trusted certificate authorities
* there is no dependency on the deployment of any new Internet
protocols or services for public key distribution or revocation.
So, yes, there is a desire to make the differences clear.
(Eric came up with a fourth bullet that didn't get included because
neither he nor I could remember it.)
Not addressing encryption?
It has a very significant impact on how the design proceeds. In fact the
need to support encryption explains much of the difference in approach.
In S/MIME and PGP signatures were largely an afterthought (Pretty Good
PRIVACY).