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]);

@nm On purpose I didn't do that becase it won't have any effect in RootOF.
Notice this:
 

S4:=singular(1/(cos(x)*sin(x)*Psi(1/x)),x);
subs(_Z=ZZZZZ,{S4}); # The substitution is made yes, but:
%; # back to _Z
RootOf(sin(x),x); # Look at the result

For more look at ?RootOf in particular the examples.

_Z is protected exactly because of its use here:
Try assigning to _Z as in _Z:=1234;
Also try:
 

restart;
local _Z;
RootOf(sin(x),x);

Notice the global version :-_Z in RootOf

@nm Here is a somewhat more automated approach. As of now it only handles N,NN, and Z.
Notice that assign is only used once.

restart;
#S4:=singular(1/(cos(x)*sin(x))+Psi(1/x),x);
S4:=singular(1/(cos(x))+Psi(1/x),x); 
idts:=indets([S4],`local`);
S:=convert~(idts,string);
idts;

resZ,resNoZ:=selectremove(s->evalb(s[2]="Z"),S);
resN,resNoN:=selectremove(s->evalb(s[2]="N"),resNoZ);
resNN,resNoNN:=selectremove(s->evalb(s[2..3]="NN"),resN);
numZ:=numelems(resZ);
numNN:=numelems(resNN);
numN:=numelems(resNoNN);
`union`(idts[1..numN]=~N,idts[numN+1..numNN]=~NN,idts[numN+numNN+1..numZ+numNN]=~Z) ;
assign(%);
S4;

@nm I did something that in your case will look like this:

restart;

S4:=singular(1/(cos(x)*sin(x))+Psi(1/x),x);
idts:=indets([S4],`local`);

idts[1]=~NN;

assign(%);

idts;

idts[-2..-1]=~Z; # Don't use _Z

assign(%);

idts;

S4;

@Axel Vogt Yes indeed. I was looking into that myself. I was first thinking of making use of StringTools.
But turning names into strings, manipulating them, and then parsing makes the variables global.
But here is another ad hoc example:
 

restart;
S1:=singular(Psi(1/x)*1/sin(x));
S2:=singular(Psi(1/x)*x/sin(x));
S3:=singular(Psi(1/x)*x^2/sin(x));
idts:=indets(`union`(S1,S2,S3),`local`);
idts[1..3]=~NN;
assign(%);
idts;
idts[-3..-1]=~Z; # Don't use _Z
assign(%);
idts;
`union`(S1,S2,S3);

To my point about not using StringTools here is the obstacle:
In my original idts above (before any use of assign) you can try:
 

idts:=indets(`union`(S1,S2,S3),`local`);
S:=convert~(idts,string);
parse~(S);
select(type,%,`local`); #Empty

@Carl Love I quite agree. I don't get those warnings though. My setting for warnlevel is 3 (the default).
I wonder why nm gets them and I don't.