No. You don't want to use an unnecessarily slow PB-KDF in your daily operations, because that means that the ratio your_speed / attackers_speed is worse.
In other words, you want the KDF that is slowest for an attacker that still completes a KD in, say, 0.5 seconds on your devices.
You are spending 2sec computing the result in browser JavaScript. The attacker will throw JS out of the window and spend 0.01sec in hand-optimized C++ or OpenCL code. You gain no security.
Because, IMHO, the attacker will always use optimized resources. Be it algorithm, cpu speed, gpu, and so on. If I double the number of interactions, it'll take more or less twice the time. For me or for the attacker. So I'll trade twice my time vs twice his time.
He can reduce his time having more cpu, gpu or finding a better algorithm.
Argon2 is slow in the browser, but isn't an inherently slow algorithm.
In other words, you have two algorithms that will each take 1 year on an attacker's machine. Option A takes 1 second on your machine, Option B takes 2 seconds. Option B isn't any better. In fact, it's worse, because it only compromises user experience and potentially leads people down the path of assuming it's more secure than it is.
Oh, so we're talking about different things (not exactly with you, but in the conversation)
I was thinking about the number of interactions (or any other tunable parameter) in the same algorithm, like Scrypt or bcrypt or PBKDF2.
Of course, you're completely right on your example: change one for another that increases time just in browser doesn't give any gain. It must be harder to the attacker...
1 second in my browser and 1 year to bruteforce on attacker's server cluster
v.s.
0.5 seconds in my browser and 1 year to bruteforce on attacker's server cluster
or
1 second in my browser and 2 years to bruteforce on attacker's server cluster
The idea is to choose the method that is most efficient for you, because doing so allows you to choose a work factor that makes things harder for the attacker without sacrificing usability.