@Brian Hanley The error I get from your first two commands is:

Error, (in plot3d) unexpected option: coloring = [ColorTools:-Color("RGB",[.50, .50, .50]), ColorTools:-Color("RGB",[.50, .50, .50])]

whereas the error I get from your comment example is:

Error, (in plot3d/options3d) unexpected option: `filledregions=true, coloring` = [cGr1s, cGr1s]

which is quite understandable since   `filledregions=true, coloring`  is a name!

Note. The code for contourplot3d can be seen here:

showstat(`plots/contplot3d`);

and is quite short piggybagging (as you said) on plot3d.
I'm using Maple 2022 as you are.

@acer I find the same error in Maple 2022.2:

Download Maple2022_2_simplify.mw

@mmcdara The error occurs also in Maple 2022.2, but NOT in Maple 2021.2.
Even in Maple 12 there is no problem although the denominator is slightly larger than the one in 2021.2.

@QM I deleted your answer as I deemed it quite inappropriate. You were "answering" your own question, which is OK in itself, but the content wasn't relevant to your own question to put it mildly.
Incidentally, I think this is the first time I have seen somebody select his own answer as the best.

@acer Thanks for pointing out my confusion. Thinking about limit and maximize at the same time must have confused me.

I ran your worksheet in Maple 2023.0.
I was puzzled by the output from the first example's convert/Diff that on my computer doesn't join the Diffs.
and therefore looks weird.
The same happened with the other convert/Diff examples.
Replacing all the Diff's in the worksheet with diff made the results look nice as it apparently does in your version of Maple.
############
This problem is also present in Maple 2022.2, but not in Maple 2021.2.
I shall submit an SCR.

@mmcdara Using your example we see another failure of maximize here:
NB: Forget about this, please. My mistake!

restart;
u := (1 + 20230321)*x*y - (x^2 + y^2)/2;
v := collect(eval(u, [x=lambda*cos(t), y=lambda*sin(t)]), lambda);
v:=combine(v);
vt:=eval(v,lambda=t);
limit(vt,t=infinity); # OK: undefined
maximize(vt); # OK: Returns unevaluated
maximize(v);  # Not OK: Returns infinity
#####
debug(minimize); # maximize(v) is basically defined as -minimize(-v)
maximize(v);

I have set default zoom at 125%.
To do that go to Tools/Options/Interface/Default zoom and choose the zoom percentage you prefer.
Press the button Apply Globally below. You can always change it if you don't like what you have chosen.

@QM DirectSearch:-GlobalOptima does fine. It is a numerical program though.
 

restart;
with(DirectSearch);
u:=20230322*x*y - 1/2*x^2 - 1/2*y^2;
GlobalOptima(u,maximize);

DirectSearch is available from the Maple Application Center for free.

Adding ranges helps.
 

maximize(u, x=-1..1, y=-1..1, location);

Obviously, the unrestricted u has no finite maximum:

eval(u,y=x) = 20230321*x^2.

I wasn't aware of your previous posting until acer pointed it out.
Now I realize that you already received answers from several highly competent people on the very same topic.

@sursumCorda I tried  besides the E result from yesterday in separate worksheets.
I used the same x and y as yesterday.
Here is the dollar code and also the results for both:
 

read "C:/Users/pkals/Desktop/tempxy.m";
x[1..10]; # Just a test

Edollar:=CodeTools:-Usage(f~(x,` $`,y),iterations=10):
# Edollar: memory used=0.62GiB, alloc change=1.21GiB, cpu time=42.60s, real time=10.48s, gc time=37.04s
# E:       memory used=0.62GiB, alloc change=0.96GiB, cpu time=42.25s, real time=9.81s, gc time=37.36s
# Yesterday: E: memory used=0.62GiB, alloc change=0.99GiB, cpu time=38.94s, real time=9.63s, gc time=34.31s

As I see it if there is a real difference then it's Edollar being worse.
In any case I can't conclude that the one is faster than the other.
In fact I think that before executing f~ the dollar is taken away somehow. Try this were a and b are just names:
 

f(a, ` $`,b); # No ~
lprint(%);
f~(a, ` $`,b); # with ~
lprint(%);

@sursumCorda  Yes, I did a test consisting in first generating x and y. Then saving them to my Desktop as an .m file.

My Maple is set up to use a new engine for every worksheet.
So in two different worksheets I did elementwise (E) and zip (Z) separately.
Here is the E:
 

read "C:/Users/pkals/Desktop/tempxy.m";
x[1..10]; # Just a check
E:=CodeTools:-Usage(f~(x,y),iterations=10):
E alone: memory used=0.62GiB, alloc change=0.99GiB, cpu time=38.94s, real time=9.63s, gc time=34.31s

and here is Z:

read "C:/Users/pkals/Desktop/tempxy.m";
x[1..10]; # Just a check
Z:=CodeTools:-Usage(zip(f,x,y),iterations=10):
# Z alone: memory used=0.62GiB, alloc change=0.96GiB, cpu time=44.97s, real time=11.24s, gc time=39.90s

Did you expect elementwise and zip to take the almost exact same time?
They don't look that way to me.
Your own results above don't look very different to me.
I tried myself:
 

restart;
x := combinat:-randperm(10^7):
y := combinat:-randperm(10^7):
E:=CodeTools:-Usage(f~(x,y),iterations=10):
# E: memory used=0.62GiB, alloc change=1.18GiB, cpu time=44.64s, real time=10.22s, gc time=39.70s
Z:=CodeTools:-Usage(zip(f,x,y),iterations=10):
# Z: memory used=0.52GiB, alloc change=72.29MiB, cpu time=15.26s, real time=6.16s, gc time=10.58s
evalb(E=Z); #true

Incidentally to me your own results about elementwise and map don't appear wildly different either:
https://www.mapleprimes.com/questions/235932-Why-Is-Map-Slower-Than-

Surely the uses of map and `~` have some overlap.
But their respective domains of operation are different.
Here are two examples where `~` doesn't work:
 

map(simplify,sqrt(a^2)+sqrt(b^2)) assuming a>0,b<0;
f~([a,b],[a,b,c]); #error
map2(f,[a,b],[a,b,c]);