I would add a fence-sitting "it depends on your use case" and what your time line is.
The cli can be utilized to build Txs without secret information. Given that light wallets following CIP 30 disclose all available UTXOs and other necessary info (not wallet secrets obvs) to build Txs on the users behalf. Light wallets generally allow users to sign a Tx, even though they cannot build them. So if you want to deliver a usable product tomorrow, this is at least feasible.
The wallet, and to some extent the cli, have been designed for personal use in the sense that they need access to sensitive information. The wallet only operates with secret keys.
To use the cardano wallet, either you force users to host their own wallet in their own instance, or you run instances and they use your platform.
The former is a technical barrier, and the latter undermines blockchain.
How well does it scale to have hosted
cardano-wallet as a service? No clue. Its trivially parallelized so its probably fine but i'm sure its not optimized for that use case.
(This has now been fixed but) For the cli, it used to require secret keys to build transactions here. Just reflective of this not being the focus of the design.
Other options: cardano-serialization-lib to build Txs in browser. There are a bunch of other nascent projects trying bridge this gap between "Technically feasible" and "Actually usable"