Question: 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?

Answer: 
The other answers were generally good, but didn't necessarilly spell everything out clearly IMHO.

1. 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.
2. 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.