The issue isn't if you want to shoot yourself in the foot or not. The issue is if you can develop general embedded solutions in a language that does not allow you to shoot yourself in the foot. You may be very safe in a padded cage, but your productivity will probably not be so high.

For embedded development, you want a general purpose language. But a general purpose language will allow you to hurt yourself if you are not a bit careful.

A language that blocks all ways of hurting yourself will contain limitations that hinders you from making direct access to the hardware. When the language adds support for concurrency - either main loop and interrupts or multiple threads - you directly get timing issues. When the language allows you to allocate memory, it may have garbage collect to reclaim unused memory but memory can only be reclaimed if the user makes sure that no links points to the memory blocks. As soon as you add general pointer support, the language will immediately get a big problem trying to add corresponding run-time bounds checks.

An interpreted version of BASIC can manage quite well, but the speed loss from interpretation can be very hurtful for embedded use. And you will probably not have any interrupt support. And compiled BASIC will open a number of ways to shoot yourself in the foot again.

In the end, we will have to live with languages that allows the user to make really bad mistakes until our tiny embedded systems gets so powerful that you don't have to care about costs of run-time checks, interpretation, functional languages, ...

What we do want is a language that is general enough that we never have to fight with the language to implement our solutions, but that adds enough structure to the application that we can keep down the support costs, and where the compiler or a third-party lint tool can find a significant percentage of logic goofs where we are about to uncontrollably wave around with a loaded gun.

Assembler is more general than C, but almost impossible to automatically analyze. And the development and maintainance costs are affected by the readability loss from the loss of enforced structure. A good developer with a good assembler can manage to write assembler code with quite good structure. But for general algorithms, it will not be possible to hide all the details in macros - extra lines of code will add to the complexity of reading the code. An assembler that doesn't allow registers to be given new names will require the reader to keep track of what data that is stored in the different registers, which takes a lot more brain power than keeping track of the contents of a 10-character C variable. And if the assembler do allow a register to be named, the reader will have to keep track of the position where there register is used with the symbolic name "A" and where the code starts to use the register with the symbolic name "B".

In the end, we want the smallest possible language that allows general solutions without requiring the developer to write too much code.