How to specify number of threads for bitcoind? What field in config file or flag should I use to run bitcoind -daemon e.g. on 100 threads? Now I have 23 threads, but I want to increase this value.

$ ps aux | grep bitcoind
pavlovd+  1258  2.3  1.7 2682460 916020 ?      Ssl  Aug05  43:22 bitcoind -daemon
$ ps -o nlwp 1258
NLWP
  23
More threads will not make your software run faster.

Threads are used in order to be able to do more things concurrently, but not necessarily faster overall. Assume your internet connection allows you to download at 1 MiB/s, and you want to download 5 files of 200 MiB each. No matter what, you need to download 1000 MiB, which will take 1000 seconds. But you could choose to either download them one by one, or all concurrently. If you download them concurrently, they'll individually progress more slowly, but overall still finish at the same time.

Your CPU has a number of cores, and can typically run one or two threads on each core (See SMT). For computationally intensive tasks, it is therefore advisable to have as many threads as you have cores, in order to keep all cores busy. However, more is not helpful in making things faster. In fact, because of increased need for communication between threads, doing so may even reduce throughput. Bitcoin Core will automatically detect how many cores your system has, and create that number of threads for transaction and block validation. If you want, you can change this number using the par setting in bitcoin.conf.

Most of the threads you see are however not computationally intensive, and are in fact idling most of the time. They're just there to deal with occasional things that need to happen in the background and not interfere with other operations. That includes threads for sending and receiving network messages, for cleaning up database files, for interacting with the user (reacting when you click somewhere with your mouse if you use Bitcoin-Qt for example), or for responding to RPC commands. For the last one, there is a setting to control how many RPC commands can be processed in parallel, namely rpcthreads. Due to locking, only 1 or a few RPC commands can actually execute in parallel, however.

So, you can change the number of threads for some tasks, but that's rarely needed, as the defaults usually get you close to the best performance. If you want to make block synchronization go faster, the best approach is increasing the database cache size (dbcache) or running on faster storage (SSD helps a lot).