I fully agree with your concerns. Especially related to parallel processing and sharding.
And modern code and design will never need this.
But there are millions of lines of old code out in the field that require these dirty tricks to survive.
And YES! You have to examine very carefully what you do.

It's a little bit like mountaineering:
Most take the cable car, some climb with ropes and a lot of fancy equipment.  While a few free climbers use nothing than their body.
You have to understand the risks and to take your decision.

#1) I'd suggest to increase the size of your LockTab as suggested by @Vic Sun 

#2) There is a class in %SYS .  ^SYS.Lock that could be useful for multiple  Lock deletes.
and as I just learned to adjust LockTab size (
SetMaxLockTableSize
https://cedocs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=SYS.Lock


#3) ^LOCKTAB from terminal command line in %SYS also shows the Locktab 

 

%VID is a Caché internal workaround for subqueries to hide the fact that ROWNUM or ROW_NUMBER wasn't implemented
https://cedocs.intersystems.com/latest/csp/docbook/Doc.View.cls?KEY=RSQL_C189621 

You can't mix it with external database access with internal features
instead, use the RowNumber implementation of your external DB (they vary by product)
https://www.w3schools.com/sql/sql_top.asp

https://docs.microsoft.com/en-us/sql/t-sql/functions/row-number-transact-sql?view=sql-server-ver15

You just can win. The workload moves to the external DB and you transfer fewer records