COVERAGE DIFFERS BY MODULE, NOT BY PREFERENCE. That sentence settles most of the argument before it starts.
The question is which one supports the operation you need — and for a given object in a given release, frequently only one does. Only after that is it a question of which you would rather write, and by then the choice has usually been made for you.
Where both are available, the honest comparison is short. REST is easier to read, easier to debug, and easier to hand to somebody else: a URL, a JSON body, an HTTP status. SOAP is more verbose, strongly described by its WSDL, and in some modules simply broader — particularly for older operations and for things that were never re-exposed.
Do not choose on aesthetics and do not choose on what you used last time. Check the reference for the specific object and the specific operation, in your release. "We use REST as standard" is a policy that meets an object with no REST resource roughly once per project, and the resulting workaround is worse than having used SOAP for that one interface.
Where you genuinely have a choice, prefer REST for anything a person will maintain — the maintenance argument from Module 3, applied to integrations: a call somebody can read and reproduce with a simple client is a call a client's own team can support after you leave.
And write the reason down at the call site. "SOAP because there is no REST resource for this object in 24C" saves the next person the twenty minutes you just spent.