I guess so. I would phrase it as improving type safety by avoiding any.
That depends on how you characterize them. In my three-type taxonomy, only the return values from type C functions are relevant. Type A and B functions should return void (as described in that post), because they are designed either so that (A) nobody cares when they finish or (B) they do care internally, but nobody outside needs to know.
This leads to another philosophical discussion about Storage. My position, as laid out there, is to write optimistically (so in my versions of these services you are writing, for example, set returns void).
I choose never to rely on Storage for in-app communication. You can do so, but if you do, then you must make set return a Promise, and you must religiously wait on every write you make before any code path may potentially read back, or you introduce a race condition whereby a read halfway across your app hits before your last write completed, thanks to one particular router change if the page has been cached on a SamBuzz K-350 phone that has just been rebooted, but only on Thursdays.
Obviously, that example is exaggerated, but race conditions do have a way of not showing up until your app is in production. I have been burned by so many I have lost count.