@psyndrome: I know it's hard to understand if you have no solid knowledge on how a computer / windows / drivers / process scheduler / really works ...

Maybe only one point .. Windows and also Mac OS are no real-time operating systems. They work all on best effort.
The process scheduler tries to distribute the workload as good as possible for normal jobs across your computers cores.
But for data consistency reasons they can not interrupt / control low level routines like driver stuff.

And there are nowadays sometimes really badly written drivers, that occupy CPU cores for to long. If an audio related process is scheduled to run on such a core, then it needs to wait until the low level routines finalized on that core and the driver routine detaches from the core. And drivers can only detach themselves from such a core.

And all this on driver level is purely regulated by "common programming conventions" .. but like the loudness war in audio we have a certain kind of companies that want to win in benchmarks. So especially GPU drivers (but not necessarily limited to those) may run a little bit longer on a core ... therefore you might see quite often GPU drivers causing higher DPC latencies on computers.

And this is only the tip of the iceberg. Your device can also have a bad design, maybe also a chipset where the USB implementation can cause issues .. from the forum I heard from RME, that this can be the case with some AMD chipsets. And you might have a bad preinstallation of Windows from the Laptop vendor with questionable and badly programmed tools, fan control, BIOS updaters and alike, which also can cause issues quite often and cause higher DPC latencies up to the point where even the GUI was totally laggy .. I had such a case in the past with a preinstalled Lenovo consumer laptop. The preinstallation of Windows was complete crap.

You can even have bad luck, that one driver runs well and if you upgrade the performance and DPC latencies on your system are worse.

And .. we all do not know exactly the resource consumption of your DAW project, where every single VST or VSTi might consume a lot of CPU resources .... Addditionally, the latencies in your DAW project can be much bigger, if you use a lot of VST as insert per DAW track ... Then you need a computer with a high Single Thread CPU, because all these VSTs need to process the audio one after the other and the more you have in a row .. the more the latency needs to be compensated in your PC ..

And you want to know whether somebody can predict, what ASIO buffersizes you need to use on your machine according to all these factors that influence DAW performance, likeliness for Audio Drops ?!?!?!

With a well optimized and powerful system, which has only very low DPC latencies (good drivers, not so long runtime of drivers on a core), then you can as a TENDENDY use lower ASIO buffersizes before audio loss will happen.
But it happens on everything. Even if you use network in parallel (interrupt load of your system) esp. WLAN is very bad (and inefficient), best turn it off in such missioncritical life szenatios ...

The short version again: you need to experiment with your hw / your drivers / your projects ..
NOBODY can tell you any good / reliable working value. Its all simply a guess not more.

Question back .. what hinders you to start your DAW projects and check / test whether you have audio drops with the lowest settings ?! And then to increase ASIO buffersize up to a value where you might get an unwanted latency (when working with virtual instruments). Usually when working with virtual instruments you need an ASIO buffersize resulting in a round trip latency (RTL) below 10ms. With RME you achieve this usually with an ASIO buffersize of max 128 samples at single speed (44.1/48 kHz). When simply recording smth with Mics, then you can use the highest ASIO buffersize, as you need only to record, playback / monitoring is not needed in such a use case.