Some languages was developed to be used for tutoring good programming style.

Pascal is such a language.

It is very good to be able to write elegant programs. But Pascal was originally intended for use on a virtual machine. So the original language did not allow access to any real hardware. Another thing is that the language contains specific "magic" that you can't reproduce yourself. One example is that read(), write() can take multiple parameters of varying type. But the language was designed so that these functions was magical - no way to let you design similar functions yourself.

Some languages was developed to be simple to implement, having very little resources.

BASIC is such a language. It is an interpreted language, because it means you don't need a compiler that have enough memory to see all of the source code at the same time. Instead, everything is based on line numbers so when the program runs, the interpreter just looks to see if it knows any text line with the specified line number. But while the original BASIC uses a very limited syntax (to make it simple to process), it also limits the developer. You can't access the hardware directly unless the specific implementation have added "magic" functions.

Forth is another such language. It isn't interpreted, but instead have removed basically all language structure. It's just a list of commands to push and pop parameters to a stack, and to operate on the data on the stack. Very good for getting good speed on slow hardware with ease of language implementation is way more important than ease of use for the developer.

Some languages have been optimized to allow very light translations from source code into machine instructions, while still letting the developer write structured programs with possibility of data types and (at least moderate) compile-time checking.

C is such a language. It gives very fast programs - in many situations you even get 1:1 relations between C instructions and assembler instructions. The very general support for pointers makes it easier to go wrong. But at the same time, this pointer support is needed to allow good mapping to real hardware since real hardware is all about addresses.

Assembly isn't a real language. It's just a way to use text mnemonics for the machine instructions the processor supports. This means that an assembler program is only valid for a specific processor architecture. And it is even possible that two different assemblers have used separate naming conventions for the op-codes or registers. Some assemblers uses the naming convention from the chip datasheets. Some assemblers are available for multiple architectures and instead uses a "normalized" naming scheme.

It is very likely that a hobbyist can get by without ever writing own code in assembler. There may be a few times when assembler may be needed, but then these specific situatins you can normally cut/paste ready-made code. You might need to be able to enable/disable interrupts, or similar.

You can write more or less organized programs in any language. But a language designed for more structured programming will help a lot. On one hand, it will force the developer to fight a bit extra to write unstructured code ;) But a language with more structure will also allow the compiler to better analyze the code and catch errors.

In assembly, you don't really have data types, so you may mix and match almost in anyway you like. In a HLL, you normally have data types. Some languages have very, very, very strict data types. Some are a little more lenient. But being strict with data types means the compiler with catch errors.

Pascal is way more strict with data types than C. In C, you may get a warning for something that is an error in Pascal. And if you add an explicit type cast in the code you tell the compiler: Yes, I do know I do funny things with the data types but I do know what I'm doing so keep quiet.

The thing is - when doing embedded, the most structured/type checked languages will start to introduce a lot of troubles for a developer. You often need to access hardware directly. You know what you need to do, but don't want to have to sit down and figure out how to best fight the compiler.

Many of the most structured languages requires you to use C or assembler to implement the hw-specific stuff just because the "main" language just doesn't allow it. In Java, you have JNI (Java Native Interface) just to be able to interface between a virtual machine and the real world.

For small microprocessors, it's C that is the #1 HLL choice just because it gives a reasonably good level of structured framework, while still limit the need for a large runtime library. And as mentioned, it maps well to most real hardware.

For larger processors, a lot of people have instead selected C++ - basically all the low-level stuff available from C but with the introduction of object-oriented concepts that can reduce the maintainance costs for really large programs. Remember that even microcontrollers are now able to run programs with 100k+ lines of source or even reach millions of source lines.

The need for software design (computer science) is directly related to the size of the programs. You can do very sloppy 100 line programs without any problem. They are trivial since they are so small you can read through the code one or two times and basically remember everything. Having a language that allows you to structure your code into real functions, with local variables and to create new, customized, data types is what allows you to write larger and larger programs without the maintainance costs going sky high. Now cost may not feel important for a hobbyist, but instead think: "Time to find all critical bugs".

So why you can use a huge number of languages to solve a problem, there will be many different criteria when trying to figure out what is a good language to use (there is almost never a "best" language).

But talking about C, you get quite a long list of "good":
- huge amounts of sample code available
- huge amounts of developers who can help
- lots of cheap compilers, books, debuggers, ...
- possible to run on PC while learning
- fits well to most common processor architectures
- results in small and efficient programs
- adds decent amount of compile-time type checking if developer thinks a bit about design choices
- adds enough structured support to work well even for quite large projects (the Linux kernel isn't exactly small)
- allows mixing with assembler - but different way depending on used tools :(
- allows most hw access directly without bringing in assembly
- ...