Well, besides performance, we need to ensure that enabling these previously disabled mechanisms won't lead to regressions or failures.
After further experiment, we can't enable the 6 message digest mechanisms since JSSE relies on message digest cloning functionality during its handshakes. Need to address 6414899 "P11Digest should support cloning" first before attempting to enable the message digests by default.
Then, as for the mechanisms CKM_DES_CBC_PAD, CKM_DES3_CBC_PAD, and CKM_AES_CBC_PAD, enabling them doesn't make much difference performance-wise. The reason is that SunPKCS11 provider uses their no padding counterpart and perform the necessary padding before/after calling the native library.
Considering that 6545046 "pkcs11_softtoken doesn't properly strip pkcs7 padding" is only fixed in Nevada and not in S10 updates, it's not worthwhile to enable the above 3 mechanisms by default.
As for the 6 mechanisms for signature, i.e. CKM_DSA_SHA1, CKM_[MD5, SHA1, SHA256, SHA384, SHA512]_RSA_PKCS, enabling them actually hurts performance when the system has a hardware crypto accelerator card which supports CKM_RSA_PKCS but not the CKM_[MessageDigest]_RSA_PKCS mechanism. When using Solaris softtoken impl, it's several times slower than the pure java provider. Need to check w/ the performance team to see if they have further input on this.
I ran my own simple test program (SigTest.java) for measuring the difference in Signature verification.
When I ran on T4, I didn't observe much difference between the two different configuration files (i.e. the default one vs. the one enabling the CKM_[MD]_RSA_PKCS mechanisms by default).
Note that even though we disable CKM_[MD]_RSA_PKCS mechanisms by default, SunPKCS11 provider will attempt to use CKM_RSA_PKCS (or CKM_RSA_X_509) as long as either is supported.
In the case of T4, both CKM_[MD]_RSA_PKCS and CKM_RSA_PKCS are accelerated, so using one or the other doesn't make much difference (at least for my simple test program).