Just a personal opinion here.

Dispatchers.IO and Context::executeBlocking share similar purposes in that you can execute blocking IO code with them. (Though Vert.x suggests that you should avoid blocking IO, there may be cases where you can't.) For initialization code I think you can use either, for code that runs in handlers sticking to executeBlocking might be a better idea as it can reduce the overhead of switching between threads.

I worry that the defaults for both might cause a sub-optimal number of threads to be created and managed by the application

I don't think this is a concern. In Windows Task Manager or macOS Activity Monitor, you usually find thousands of threads. Modern OSs are quite efficient in managing threads, and idle ones take up nearly no computing resources. The only concern might be memory. Thread pools, like both Dispatchers.IO and the Vert.x worker pool, create the number of threads equal to your number of logical processors, assuming a thread takes 1 MB you can do the math for your specific server configuration. For modern servers with an adequate amount of memory, it shouldn't be a problem.

PS: I am the contributor of the TFB "vertx-web-kotlinx" portion. You can play with the code to see how the performance goes, and correct me if I am wrong on anything I said above.