Are hash functions "intentionally" designed to be efficient? I am curious to know if the hash functions are intentionally designed to be fast, or it happens to be like this. This is very interesting to know because on the one hand, efficiency is not considered as a property to design a hash function. On the other hand, if they are not efficient, a lot of applications and protocols will be affected, e.g., the hash chain.
It seems your question is about design / choice criteria for hash functions, so let's go through all of them (or at least the more important ones).


Basic security. If your hash function fails to provide the basic security guarantees, e.g. 2nd and first pre-image resistance and collision resistance, there's no chance it's ever going to be used.
Advanced security. This is also a "must-have" for hash functions these days and includes things like "acts like a PRF" or "can be modeled by a random oracle".
Speed. If I have the choice between two hash functions that are equally secure for my purposes, I'm always gonna pick the faster one, unless there are other good reasons to pick another one.
Endorsements. As everywhere, if you have a good "marketing department" your product is gonna be widely used. This also holds true for hash functions which benefit massively from endorsements such as "SHA-3 finalist", "SHA-3" or endorsement by NIST, BSI, ...
Elegance. Many good hash function designs try to be simple but effective to ease analysis and give confidence that no "hidden problems" can be found because it's all "so simple".


To go a bit further into the speed side, you want your hash function to have a nice synergy with your hardware. E.g. Keccak has been designed to be fast once the gates for the the $\chi$ step will be integrated in the hardware (this is why hash competition have VHDL design requirement).