Generalize threading settings in proxy building and use them for encoding/decoding in general.
Check codec capabilities, prefer FF_THREAD_FRAME threading over FF_THREAD_SLICE and automatic thread count over setting it explicitly.

ffmpeg-codecs man page suggests that threads option is global and used by codecs, that supports this option.
Form some tests I have done, it seems that av_dict_set_int(&codec_opts, "threads", BLI_system_thread_count(), 0); has same effect as

pCodecCtx->thread_count = BLI_system_thread_count();
pCodecCtx->thread_type = FF_THREAD_FRAME;

Looking at ff_frame_thread_encoder_init() code, these cases are not equivalent. It is probably safer to leave threading setup on libavcodec than setting up each codec threading individually.

From what I have read so far, frame multithreading should be faster than slice multithreading. Slice multithreading is mainly used for low latency streaming.

When running Blender with --debug-ffmpeg it complains about pCodecCtx->thread_count = BLI_system_thread_count() that using thread count above 16 is not recommended. Using too many threads can negatively affect image quality, but I am not sure if this is the case for decoding as well - see https://streaminglearningcenter.com/blogs/ffmpeg-command-threads-how-it-affects-quality-and-performance.html This is fine for proxies but may be undesirable for final renders.

Number of threads is limited by image size, because of size of motion vectors, so if it is possible let libavcodec determine optimal thread count.

Performance difference:
Proxy building: None
Playback speed: 2x better on 1920x1080 sample h264 file
Scrubbing: Hard to quantify, but it's much more responsive.
Rendering speed: None on 1920x1080 sample h264 file, there is improvement with codecs that do support FF_THREAD_FRAME for encoding like MPNG