A long time ago, computers didn't have bootstrap ROM. One had a direct interface to modifying RAM, and could halt the CPU, change RAM, and then restart the CPU. So, when you restarted the system, you had to make sure the CPU was halted, enter your bootstrap code that would load a second stage bootloader (2bl) off of paper tape or whatnot, and then "unhalt" your CPU.
ROM saves the day here, obviously. When you power on an x86 CPU-based system, it begins executing at address FFFF:FFF0. That's a hardwired feature of the x86 CPU. ROM has to reside at that address, and indeed the very upper part of the BIOS does (usually starting at E000:0000).
The term BIOS is a holdover from the old CP/M operating system. The structure of CP/M was the ROM BIOS at the lowest layer, the BDOS (Basic Disk Operating System) in the middle, and the CCP (Console Command Processor) in front of the user. The BIOS had routines to perform low-level functions such as reading/writing a specific disk sector, reading a key from the keyboard, writing a character to the screen, etc. The BDOS would use BIOS functions to implement a file system, and the CCP would be the command shell using BDOS and BIOS functions. The idea was the BIOS would contain the hardware specific interface, and the BDOS and CCP could be the same on any CP/M system.
The BIOS would also hold the initial code executed by the processor, which initialize required hardware, display a splash screen, load the 2bl off the first sector off of the first disk drive and run it.
MS-DOS 1.0, pretty much being a x86 implementation of CP/M, with kludgy Unix-like features added on starting at version 2.0, was structured the same way. The IBM PC BIOS at that time also included enhancements such as video mode switching, graphics functions, and hard drive support in the original AT BIOS.
However, most DOS programs did not use BIOS functions once they started; they directly accessed hardware for performance reasons. This was especially important after 32-bit CPU's became commonplace; the BIOS only worked from the older 16-bit mode, so calling it from 32-bit mode incurred a further performance penalty.
Around the 1990 the PC architecture was beginning to be extended, and starting to include new stuff like APM, PnP, and PCI. So the BIOS was starting to take on additional functions and get bigger. PCs also were starting to use chipsets instead of discrete components. Initializing the chipset is something that needs to happen to get RAM and other components such as the PCI bus usable, so that has to be handled by the BIOS bootstrap code. For some reason many chipset vendors do not like to document how their setup processes work.
APM was handled by BIOS functions; i.e. to power the system off the operating system had to call an APM function. ACPI, APM's successor, is the big thing BIOSes do today. The ACPI BIOS is responsible for creating a bunch of tables in memory that describes many non-plug and play hardware components. A booting operating system uses this to determine how many CPUs there are, how many RAM slots the system has, whether the system is a desktop or laptop, how many batteries are installed, etc. The ACPI BIOS also must be called to power off the system, or place it into sleep, etc. There's no reason that operating system code couldn't handle ACPI calls, though.
Most of the time BIOS updates are to fix ACPI errors, since ACPI is complicated and difficult, or to introduce enhanced microcode. All modern CPU's allow microcode updates, and if a new microcode update is released the BIOS must then be updated to install that new microcode. It's possible for a normal program to update a CPU's microcode.
SMI's are also handled by the BIOS. I'm pretty sure most of the thermal and power related hardware in a PC triggers SMI's, whose routines then adjust fan/CPU speed and/or other things. Other things can trigger SMI's; check out the Wikipedia article on System Management Mode. But there's also no reason that this code couldn't be replaced with operating system code if hardware interfaces were documented.
Modern operating systems do not use the BIOS at all for hardware access, except for power events. Some bootloaders do use the BIOS character I/O to display text and disk I/O load the OS boot code.
So I hope this sheds some light on the BIOS's role, and for the most part you are absolutely right about how it works.