openssl pkcs12 -export through 1.1.x by default encrypts the privatekey (in a PKCS8 'bag') using the scheme
pbeWithSHAAnd3-KeyTripleDES-CBC defined in PKCS12 aka RFC7292 appendix C which uses 3-key TDEA aka 3DES (as it says) and the PBKDF defined in appendix B with SHA-1, 2048 iterations and 8-byte salt; this doesn't appear to have an official name so I just call it PKCS12PBKDF. This seems to be an unwritten convention; all other programs I know of that create PKCS12 also use this scheme, at least by default and sometimes unconditionally. (Update: after 2020 this started to change; some other things now use PBES2 almost always with AES.) In OpenSSL you can use
-keypbe to specify any PKCS12 scheme (or any PKCS5v1 aka PBES1 scheme, but don't because they're all obsolete and broken) or the PKCS5v2 PBES2 scheme with any supported cipher (in CBC mode) but always with PBKDF2, (corrected) SHA-1 through 1.0.x or SHA-256 in 1.1.x up, 2048 iterations, and salt. Although PBKDF2 is technically different from PKCS12PBKDF, the differences don't matter to security AFAICS.
Update: 3.0.0 (released in 2021) up defaults to PBES2 with SHA-256 and AES-256, although you can specify
-legacy [-descert] to go back to the long-conventional PKCS12 schemes (SHA1 and 3DES for key, either that or SHA1 and RC2-40 for cert).
This fixes the most glaring flaw in OpenSSL's 'legacy' PEM-file encryption, that it uses only one iteration of MD5. (Using MD5 is not a problem in itself; although MD5 is badly broken for collision, that doesn't apply to a PBKDF. But since the letters MD5 now provoke irrational panic in checklisters, managers, and other fairy-dust believers, and we have better hashes available, we use them.) But 2048 iterations is not great; it was considered adequate when PKCS5v2 was published back in 2000 but hardware has improved a lot since then and nowadays 10s or 100s of thousands are usually preferred, and some go for millions or more. More importantly, hardware has changed to make raw computation more available in the form of GPUs, FPGAs, and even ASICs, so nowadays an iterated hash is no longer best practice; instead we want a 'memory-hard' function like scrypt or Argon2; see e.g.:
In 2018, what is the recommended hash to store passwords: bcrypt, scrypt, Argon2?
Are there more modern password hashing methods than bcrypt and scrypt?
Is bcrypt better than scrypt
Do any security experts recommend bcrypt for password storage?
How to securely hash passwords?
Why are salted hashes more secure for password storage?
How are SCrypt's memory-hard requirements substituted with more CPU?
Has scrypt been broken, finally?
If you want the most secure private key encryption in OpenSSL 1.1.0 up (these versions are now widespread though not everywhere) use
openssl pkcs8 -topk8 -scrypt plus optionally
-scrypt_[Nrp] $val if you want to customize although the defaults should be satisfactory. Note however this is not necessarily portable to anything other than OpenSSL. You can also use PKCS8 with PBES2/PBKDF2 but increase the iterations with
openssl pkcs8 -topk8 -iter $num (1.1.x up defaults to PBES2/SHA-256/AES-256 but for 1.0.x or lower specify
-v2 aes-256-cbc or similar); this is much more interoperable and probably secure enough (given a good password). (As I noted on a different answer to the Q you link.) Update: as @muxmuse comments, for 3.0.0 up
pkcs12 -export also supports
-iter N -- and as noted above also defaults to PBES2/SHA-256/AES-256.