Is it generally okay to substitute “like for like”? Is it generally okay to substitute “like for like” in cryptographic protocols?

For example, many lattice protocols use SHAKE and SHA3 for various purposes.  However, both of those are relatively slow in software.

If I substitute Blake2X and Blake2b for these respectively, will the resulting (incompatible) protocol still be secure?  Similarly, if a protocol calls for an AEAD, and specifies AES-GCM, can I substitute ChaCha20-Poly1305 instead and still get a secure protocol?
Broadly speaking, the answer is yes IF the protocol was designed to be modular and not depend on any particular properties of the underlying algorithms. 

If the protocol has a proof of security that abstracts the underlying primitives (i.e. if the theorem statement contains a phrase like "Let $blah$ be an AEAD scheme" and the proof contains a reduction to the AEAD security of $blah$) that proof should still more or less hold. If there is no proof of security you have two options: (a) write one and make sure the reduction goes through or (b) just make an educated guess. I recommend (a).

Some details, in particular exact security bounds, may change slightly when different primitives are used. For example, AES-GCM has a relatively low authenticity bound compared to something like AES-CTR-HMAC-SHA256. This really only matters if you're planning on encrypting huge numbers of very large messages with the same key, but it's worth checking nonetheless.

Standard caveats about side-channels and things like that apply, obviously.

EDIT: Just saw your question asks about hash functions too. Hash functions are sometimes trickier to reason about, especially if the random oracle model is involved. If the protocol is just reducing to the collision-resistance of the hash function, swapping one good hash function for another is probably fine. However, if the hash function is being used to instantiate a random oracle, you need to make sure the hash function you want to swap in is indifferentiable from a random oracle. So, for example, it's not ok in general to use SHA256 in place of SHA3, because the former is not indifferentiable from a random oracle.