Even compared with C, assembly gives you minimal guardrails, which makes it harder to write correct programs at scale. An e-commerce web app is going to be a large program that's online and an attractive target for attackers. You will need more discipline, experience, and tooling to prevent bugs, including bugs only made possible by your choice of language. (For example, assembly opens up a category of control flow bugs that are prevented by structured control flow. Data corruption is easier because you don't work with named, scoped variables.)
It isn't a question of "could" but how likely you are to get good outcomes.
A big reason not to write enterprise web backends in raw C is that segfaults (the most common symptom of programmatic errors) abort the whole program. One person writes one bug, and when that bug is hit the whole backend crashes.
The risk of bugs goes up when lots of people (with different timelines/skill levels/expectations) are working on an enterprise codebase. Ergo, the risk of "entire backend vanished" crashes goes up over time. A huge benefit of HLLs is that they have a vastly reduced risk of whole-program-aborting bugs--even Erlang, with it's "let it crash" philosophy, is referring to letting the boundary of affected code within a larger program crash, not aborting every transaction/reinitializing all resources and restarting from scratch.
Things like CGI mitigate this a little bit by containing the blast radius to one request's handler (at a pretty severe complexity/performance/compute cost to things like shared connection pools/file handles/startup time), but they don't solve it. The same is true for things like autorestart services/orchestrators.
Sure, you can decline to abort in the event of a segfault, but that's .... ballsy, shall we say.
Sure why not. If it can process my transaction cleanly and securely why not?