Each point of view has its own merits. Certainly the paper point of view has intuitive simplicity and is acceptable for applications where it meets the needs.
The protocol point of view can come close to encompassing the paper point of view as a limiting case. In particular, it does so in the following circumstances:
In these cases, the protocol point of view would be narrowed to something close to the paper point of view. Even when the paper point of view is questionable, the extension of a protocol, such as adding optional lack of canonicalization and/or optional policy statement/pointer/semantic label inclusion, will usually satisfy the perceived needs of individuals holding a paper point of view.
On the other hand, the paper point of view is difficult to stretch to encompass the protocol case. From a strict paper perspective, canonicalization is wrong; inclusion of human-language policy text within every document and a semantic tag with every adjunct would be mandatory; and so on. Objects designed in this way are rarely suitable for protocol use, as they tend to be improperly structured to accommodate hierarchy and complexity, inefficient (due to unnecessary text and self-documenting inclusions), and insecure (due to brittle signatures).
Thus, to produce usable protocols, it is best to start with the protocol point of view and add such paper-perspective items as are necessary to gain acceptance.