::: spoiler A lot depends on the overall systems.

If you're really interested in the subject, here are the places to look around:

1. OpenWRT is the goto embedded Linux starring point. It is hard if you're only familiar with desktop distros that use the Bash shell as the default. OpenWRT only has busybox with the Ash shell by default. OpenWRT is common on routers and is an entire distro that fits within 8-32 MB of flash memory on these devices or others like single board computers. Often, using an old router board just to hack around like it is an SBC is a great way to learn.
2. Try working your way through a Gentoo install on any old computer. Unlike Arch, Gentoo is a foundational distro that has a plethora of tutorial based content to guide you through all the different parts of an operating system. Gentoo packages very little for you in binary form. It shows you how to compile almost everything and allows you to learn how to customize and compile and package to your liking. You will likely need advanced-intermediate level skills to cope with the competence level that Gentoo assumes in documentation. Docs are written from the foundation up, but they assume infinite ability to learn and do not continue to hold your hand. By contrast, Arch de facto assumes you have a CS degree and have completed all courses on POSIX operating systems in how pacman is managed. Arch provides an excellent set of reference documentation, but is a fractal bottomless links chasm if you try to use it like a tutorial for contextualization like what Gentoo offers. If you ever wish to learn the next level and what Gentoo is actually packaging for you, Linux From Scratch (LFS) is a thing.
3. On a more practical side, base Debian is another foundational distro. It serves two primary purposes. It is the stable distro of choice. This means that most packages and libraries are frozen in time and only updated for security patches or packages that maintain backwards compatibility as an absolute priority. If you're building some project using a bunch of high level Linux stuff but it needs to be safely online, doing so on a long term supported stable distro means, once the project is up and working, keeping the software up to date should not break anything. Debian is also the primary hacking distribution where hardware support for Linux is done. There are a bunch of Debian specific tools to get into and boot new hardware, called bootstrapping. This is how there is support for many hardware devices that have no public documentation or OEM support. The wonderful folks within this space make much of our world possible. I mention this one because a lot of the things happening with the initialization of hardware are better fundamentally documented in this space.

These are the places that I learned the basic lay of the land in this space. The boot up speed is a combination of the way the bootloader is configured, how the handles for hardware interfaces are initialized, how well the Linux kernel can trust these interfaces, and all of the software that is initialized before the user space.

Android does not require the end user to know anything about the device, networking, or OS best practices. It achieves this by eliminating the administrative user and any kernel packages that could modify the kernel or install an administrative binary. Then, Android makes all installed app developers full users on your device so that they may use their knowledge to configure all of the required interfaces and security. You ultimately have all of the same access as they do, but you are not the administrator or have any effective say over what they are or are not allowed to do on the device. There are a few measures to help block off some behaviors, but these are more like frivolous gestures to make you feel a little better rather than any kind of authority.

The reason your device gets depreciated and must be periodically replaced is because google packages the Android version of the Linux kernel with everything setup so that only the kernel hardware modules (drivers) required for the specific device need to be added at the last minute. These modules are only added in binary form at the last minute. The source code is never made public and these modules are not part of the mainline Linux kernel. This is the only reason your kernel is not updated regularly and is likely very VERY old with many security vulnerabilities. The manufacturer might recompile and send you an updated kernel if a CVE happens that enables remote code execution, but this is only likely if they have a substantial inventory of devices in the warehouse that have not already sold. It has nothing to do with you or ethical behavior. If the hardware supporting kernel modules code was merged with the mainline kernel, your devices would stay up to date with all the kernel security updates for decades automatically. If this sounds wrong, let me warn you now, saying so will put you in the Stallman camp where you will be labeled as a crazy extremist. This is the specific reason for Stallman's insanity by his detractors. Stillman's argument is that you don't own your device.

These proprietary binary kernel modules are one of the primary aspects of boot speed. There is no telling what is happening on these levels when the device has proprietary binaries.

The system works with a bootloader that powers everything in a specific order and creates handles. The handles are passed to the kernel. The kernel initializes and starts running kernel space stuff. One of the main things it is doing is abstracting memory spaces.

If you've ever seen the earliest personal computers based on the microprocessor chips like the 6502 in an Apple II, they always had a RESET button. This is because a crash in the code crashed the actual hardware. In modern computers, your user space software only runs in virtual memory. This dies not require a reset because, while your software might still freeze, it is only running virtually. There is also a CPU scheduler that is handling interrupts (like key presses that can not wait, or background tasks) and power management works with this as well. When your software freezes, in theory, the kernel processes that are actually running on your hardware still get their time to run in kernel space priority on the CPU and their memory is protected from the virtual memory space of user software using virtualization.

Okay, all this bla bla bla is to say, if the device in question has no outside connection, and if the software can not change, and if the manufacturer is the one creating the bootloader AND kernel AND user space application all of this chain can be greatly simplified and bootup can happen lightning fast. This is called embedded Linux and is the most common form of Linux.

Android also has a system called Zygote. This preloads all of your apps when the user space loads. The user space on Android is actually like a single Linux application that runs on the Linux user space. The justification for Zygote loading everything in advance is because it makes everything load faster. Thus is what it says in documentation. Benchmarking shows that the difference is orders of magnitude smaller than your persistence of vision. In other words, it only exists to boot up the other dev users before you are loaded as the final ~~product~~ user. This is why you should not run any apps you do not exclusively trust. These app developers are like your bedmates but more intimately in contact with your person all the time. This is why everyone wants you to install their app. The google framework of Android is essentially a pimp and you are the product.