>>(with p[ad] and p[us] in best cases close to 0, but p[ad] probably still lower due to more security measures and habits server side, but more users than admins)
for attack vectors like keylogging after having infected one machine able to send SQL to the backend. For most scenarios the probability (1="total difficulty", inaccessible) server side will be higher. Slashing a couple of possible attack vectors is IMO worth some developer ease IMO.

Recent reviews in healthcare say that keyloggers and other crimeware causes 1.4% of data breaches and cyber espionage 0.3%. Almost 50% of breaches are lost or stolen data. Not via applications, but mostly misuse of super access rights to create illicit data caches that get stolen. The biggest culprits are sysops and data analysts with direct access to data. Crucially, theft of an encrypted dataset is not counted as a breach, meaning that the biggest issue is people with super access repeatedly creating un-encrypted caches that get stolen.

20% of breaches involve misuse of application access, most often serial inappropriate accesses by non-clinicians, while "error" including faxing or emailing to wrong addresses or loss of a thumb drive with patient info, is another 20%

In view of the above, seems to me that security improvement has little to do with how the app accesses data. Biggest bang per buck has to involve securing the SA password/locking down super access rights so that illicit unencrypted caches can't keep being made, followed by peer review audit of all privileged users to help spot abuse via applications, followed by automated electronic transfer to avoid accidental faxing or emailing to wrong addresses. Typically the sysops will want to focus on the minnow security issues while keeping their own super access, but in view of the stats, the whole "do as I say, not as I do" theme needs to be looked at.