Most of these operations are "trivial": they replace combinations of two or three existing opcodes. For instance, the
BLSR type of instruction is, as specified in the page you link to, equivalent to a subtraction followed by a bitwise
AND. This could already be done. Extra operations don't harm, and compilers will benefit from them, and, undoubtly, some cryptographic functions will gain a few cycles through use of some of these opcodes, but there is no groundbreaking result to expect.
Among the instructions, the most interesting are the counting ones (
TZCNT) because counting the number of leading or trailing zeros in a register of N bits has cost O(log N) when using "classic" opcodes. These operations have some use in some corner cases of computations on big integers. In particular, I think this will help for binary GCD, which is used to compute divisions in finite fields -- an important step in computations over elliptic curves. Right now, division in finite fields is so expensive (when compared with multiplication) that it is worthwhile to use projective coordinates to compute things on elliptic curves: this implies about ten times as many operations, but avoids a lot of divisions, so it adds up to net gains. A fast implementation of binary GCD might change that picture a bit. For more uses of counting operations, see this Wikipedia page.
What may really boost things up is not the new instructions, but the larger registers. AVX2 offers 256-bit registers; that's room enough to compute eight SHA-256 in parallel, just like SSE2 allows for four parallel SHA-256. Password cracking software will benefit from this... (although GPU are arguably better). There is ongoing work for defining tree hashing modes for turning a given hash function into a system which benefits from parallelism; e.g. see this article (from the Keccak, aka SHA-3, designers). NIST has expressed their will to define some standard in that respect.
Of course, it still takes some particular scenario to benefit from such CPU gains. In most uses of hashing (or encryption or whatever), the cryptography is not the bottleneck; I/O is. When you hash files, you cannot hash them faster than you can read them from the disk.