In general, after we design a secure cryptographic protocol and make sure that it is efficient (e.g., through complexity analysis), we implement it.
Questions:
I assume the question is related to academic work: why do we implement a protocol if we already know how efficient it is by a complexity analysis? The answer depends very much on the type of protocol. However, the answer typically is that a theoretical complexity analysis usually does not suffice to understand the concrete efficiency. If the "previously best known protocols" required a certain number of operations and your improvement is exactly the same but with less operations, then this could suffice. However, this is rarely the case. Rather, your protocol may have less exponentiations but more communication; it may have less symmetric operations but be less memory efficient. It is almost impossible to really know that it's more efficient without implementing it.
Another issue, which is certainly the case in secure multiparty computation (where I work), is that implementation helps us understand what the bottlenecks are. In fact, we are very often surprised at what the "expensive" part is. In just one example, in this paper (sorry for the self citation, but it's just a good illustrative example), we were very surprised to find out that a large percentage of the time went on a matrix inversion which had nothing to do with the cost of the cryptographic operations. Without implementing, we never would have found out about this.
One thing that as a field we have to improve upon is the quality of our work in this sense. We don't have good benchmarks and implementations and comparisons are all very ad hoc.
I will finish with one final comment. Despite the above, not all new protocols need to be implemented in order to be published. When the protocol contains an important new idea, or when it clearly beats the previous work, then it can be published without an implementation. However, follow up work with implementation is always important. (Of course, protocols whose claim is that of asymptotic and theoretical efficiency never need to be implemented.)
Do we implement it for proof of concept?
Absolutely. It's very easy to miss vital points if no implementation exists. W3C for instance doesn't even allow protocols to be standardized without reference implementation(s). Furthermore, an implementation may show small improvements as well.
Personally I would require an implementation of all the (minimal) options as well. If there are too many options for that, then the protocol is likely too complicated. In that case the design needs to be simplified or a choice should be made which parts should be part of minimal implementation requirements.
Note that the number of protocol types explodes exponentially with the number of options. E.g. if a protocol contains 3 block-ciphers, 3 key sizes and 3 modes-of-encryption (that can be freely combined) then you already have to implement and test $3 \times 3 \times 3 = 27$ combinations.
To provide an example, I know of a protocol that used AES-128, AES-192 and AES-256 only to find out that there was a problem because 192 is not a multiple of the 128 bit block size of AES.
A reference implementation may also provide clarification where a protocol is not completely clear. In other words, it can be used to find out the intent of the authors of the protocol. If this is the case then obviously the formal description of the protocol should be adjusted in the end.
Do we implement it to support our claim that the protocol is efficient?
This, in my opinion, is less important unless the protocol is designed for applications that require a very precise definition of efficiency on a specific platform. The reason is not that efficiency is not important; The efficiency can however normally be calculated pretty accurately.
Furthermore, efficiency is very implementation specific, so just publishing results for a reference design may not paint a complete picture. Optimizing the reference implementation may also compromise the readability and the chance of errors. Separate implementations for specific platforms are often used instead.
Notes:
