I mean, if binary code is already generated by PC, wouldn't it be possible to just take this binary code, transfer it to a specific place in flash memory via specific bus, for example Serial Wire, and it would work?
Why is a programmer usually required in an embedded toolchain?
That's what the programmer does.
It takes the binary output from the compiler and stores it in the MCU's Flash EPROM, usually over a serial bus.
Flash EPROM requires a programming algorithm to store data in it, with any erases first. The programmer carries out this algorithm. It's not like writing data to RAM. This is very well documented and explained on the Internet.
A programmer is the implementation of " via specific bus,". Some devices have inbuilt bootloaders (may be hardware or software or firmware) that allow the use of a port of some sort to load code.
Whenever a feature is included in a device that is not utilised during normal operation it adds an unproductive overhead. On very large and capable systems this overhead may be small and unimportant. On very small systems it may occupy enough program space or hardware to represent a significant degradation of device capability. When processors get into the cents per unit range every last piece of capability is worth having. (A 2 cent processor that becomes a 3 cent processor due to added little used capabilities may matter. )
transfer it to specific place in flash memory via specific bus
This is exactly what flash programmer devices do. They just don't use something slow and archaic like RS232, but instead nowadays usually JTAG/SWD. Often translated to/from USB.
A high speed bus like JTAG is required to enable two things:
For example in the dark ages where one built everything from scratch, I recall things like RS-232 bootloader with 9600bps and handshaking, then EPROM programming times on top of that. It could take as long as 20 minutes just to program a single MCU.
Before the early 2000s, pretty much every MCU family had its own special snowflake programming interface, which was far from standardized. These were horrible, horrible things. Then came various proprietary single-wire debugger interfaces and eventually JTAG/SWD which became industry standard with the advent of PowerPC and ARM.
You can of course still use bootloaders over USB, CAN, UART etc and many MCUs have built-in hardware support for it even. But these are meant to be used for specialized use-cases and not for production batch programming.
The ability to self-program has a number of costs, and generally these costs can be avoided by leaving that ability out:
The other answers were generally good, but didn't necessarilly spell everything out clearly IMHO.
To load a compiled program into a microcontroller, the PC that holds the compiled program needs to be connected directly to the microcontroller in some way that provides a method of bidirectional communication. That's one of the jobs of a programing device: to provide that communication path.
Some microcontrollers - but not all - require high voltages to program. By high voltage, I mean higher than Vcc. Providing that voltage is another important function of the programing device.
Every microcontroller that I have experience with allows the possibility of programming it with a so-called bootloader. On power up (or reset) the bootloader looks on one or more specific communication channels for someone trying to replace the existing firmware with new. If it finds that to be the case, and everything checks out security wise, then the bootloader accepts the new firmware and puts it in the place of the old program. This is very often done with commercial products that allow firmware updates by the user. Note that this requires the bootloader to already have been loaded into flash memory by 'conventional' methods. So we still haven't solved the problem of programming a fresh chip.
In any case, the bootloader takes up some space in flash memory which may or may not be precious.
Having said all of that, some microcontrollers can be programmed without special voltages. The AVR series is a good example. These still need some sort of hardware to connect the software on your computer to the digital pins on your microcontroller (and software on the PC to make it work, obviously.) You can get everything off the Internet to turn an unloved Arduino into a programmer for AVR chips. This takes care of requirement (1) above, and since AVR chips don't have requirement (2), Bob's your uncle.
As a point of interest, I once built an instrument that was controlled by a Raspberry Pi. It turned out the RPI couldn't provide certain signals that I needed with adequate timing requirements. I looked for an existing IC that could do what I needed, but couldn't find anything. So, I used an ATtiny85. I wrote some simple software to make it into my dream chip, and programed it directly through the RPI digital GPIO. No programmer required. It turned out to be both easy and fun. But, circuit design and microcontroller programming are always fun for me
Not all microcontrollers need to be programmed via protocols and connections designated for a debug probe or programmer device.
As an example, the STM32F446RE microcontroller has two boot pins that control if the microcontroller executes the program stored in its (main) flash memory, if it boots from its SRAM, or it it boots the program from its so-called "system memory". This program overwrites the main Flash content with a new main payload program transmitted via UART, CAN, or SPI (where the ports and pins to be used in each case are fixed and can be looked up in the documentation). In this way, the microcontroller can be programmed with a standard USB-to-UART device, via the CAN bus, and so on.
But during development, you often want to use a debug probe anyway, and using that to also program the microcontroller is often more convenient. For firmware updates in the field, the possibility to program from the system memory program can however be useful. It is not possible to overwrite the system memory program as far as I know, so the MCU cannot be bricked in this way.
