I've been using the Active Choices plugin for a while, and having a job that uses more than 10 parameters whose values are resolved from remotely hosted files, I eventually started to observe a weird issue going on in my multibranch pipeline job since some months ago.

On the first build of every new branch, which creates a new job with initially no parameters as those are defined in the pipeline code itself, I got a stage that typically took around 10 to 20 seconds starting to take a lot more time to finish, around 20 minutes or more.

After debugging for a bit, I realized that on every access to the params map, Jenkins was resolving the defaultValue of every parameter that I defined, understandably as that build did not start with any parameters, so Jenkins probably falls back to using the defaultValue that was just defined for the parameter. For AbstractScriptableParameter parameters though that has an expensive consequence, as their getDefaultParameterValue override executes the script (follow getChoices -> eval -> new ScriptCallback), which in my case could took up to 3 seconds to run, depending on how the network was feeling at the moment.

This is made worse by the fact that every access to any parameter value, even to parameters that are not from this type, seem to be recalculating the default value of all the parameters, in series. So my case exploded because I did the worst possible combination, having many AbstractScriptableParameters and having a stage that evaluated a lot of parameter values.

Attaching a repro pipeline that you can use in a pipeline job (no need for multibranch) which reproduces the issue every single time, as I remove the parameter definitions at the end of it, and that retriggers the same situation. Make sure to approve this signature for the scripts to be able to run:
staticMethod java.lang.Thread sleep long
Notice how every evaluation to params runs all the scripts again, ending up with a build of more than 1 minute, and we're just evaluating params.