why are certain things usually taken care of by the hardware, while other things usually by OS?
It is not an either/or situation, but rather the case of "the software (the OS and user programs) directs how and what the hardware should do". In other words, the software is always doing something and the hardware is always doing something.
Occasionally there are intervals when software is waiting for a hardware operation to complete, so interrupts and multitasking were invented to improve overall efficiency of the computer. When there really is nothing to do the OS is forced into an idle loop/process. For every instruction cycle, the software has to do something or else execute a hardware HALT (or SLEEP) instruction.
Occasionally there are intervals when a hardware operation is waiting on another HW operation to complete, for example when a memory cache miss occurs and data has to be read from main memory (so the CPU has to execute wait cycles). But for every clock cycle, the hardware has to do something.
Your question might be alluding to tasks that could be characterized as CPU intensive versus I/O intensive. That is, some jobs like copying files, require a lot of data transfers, and waiting for that I/O to complete rather than using CPU cycles. Other jobs like calculating prime numbers, require a lot of CPU cycles and almost no waiting for any I/O to complete.
Addendum
Perhaps your original question is based on queries of "how does X work?", and there are replies like "the OS does this" or "the hardware does that". The problem with (simplifed) answers like that might lead to your original question. Those answers are based on the responder's perspective or where the functionality was (essentially) implemented or easily explained.
An answer like "the OS does ..." implies that the functionality is essentially implemented in software. The implication is that the software is executing on a rather standard hardware platform.
An answer like "the hardware does ..." implies that the functionality is essentially implemented in hardware. The implication is that the executing software has activated or using this hardware to perform the functionality.
Note that there is a fine (or is it fuzzy) line as to where functionality should be implemented. Most programmers think that a high-level language has to be compiled (into machine language), but there have been computers that can directly execute "high level language" (aka "direct execution"). As hardware costs get cheaper and/or there is a demand for speed, there is a migration of some functionality that was previously in software to get implemented in silicon (e.g. audio and video encoders and decoders). RISC processors took the opposite approach by making the instruction set rather simple, which throws some complexity back at the software and OS. Sometimes what is "done in hardware" is a "blackbox" or dedicated integrated circuit that, if you look deeper, is composed of an embedded processor with RAM, ROM (for firmware) and peripherals to comprise a subsystem.
Example
If you ask "how does virtual memory work?", you'll probably get an assortment of answers, some with a decidedly software or OS viewpoint ("the OS does ...") and some with a hardware viewpoint ("the hardware does ..."). Ideally answers should show how software and hardware have to interact (and how the entire operating system has to be designed) to accomplish something like virtual memory. For instance:
- An instruction in a user program references a memory location;
- That location causes a page fault:
- The user program is suspended, and the PF interrupt handler is executed.
Determining that there is a page fault is usually done in HW (the memory management unit), but the OS has to provide an interrupt service routine to deal with that condition. The software and hardware comprise a system.
