Game Boy games do not always need a manual save operation. There's no hardware reason that would prevent Game Boy games from saving in the way you describe.
For the Game Boy hardware, RAM present on the cart can be used by games for whatever it needs.
SRAM is RAM on the cartridge; most of the time, it's backed up by a battery and used to store save data, but some games also use it as extra work RAM (Pokémon games use SRAM as scratch buffers for sprite decompression, Super Mario Land 2 uses some of its SRAM to store variables and level data).
(Also note all these answers should apply to most of the 8- and 16-bit consoles, I'm thinking of the Mega Drive specifically, since that has the simplest cartridge interface.)
I think there might be a few Game Boy games that have smaller saves, say high scores only (Kirby's Pinball Land?), that do save automatically. Doesn't Super Mario Land 2: Six Golden Coins save automatically on completion of a level?
To take your idea of using SRAM directly for live save games: For a game save to be useful, there needs to be a known-good-state in SRAM to load from, and this has to be the complete state of the game you want to save. Actively updating the game state in SRAM results in loss of the known-good-state quality while the current frame is being executed. While you're running the game, you're constantly modifying the game's values, and this process isn't a single indivisible 'atomic' operation. Take a Pokemon example: when the player walks into a house, you've got to change their current map/room number and then place the player's X,Y at the corresponding entrance of the new room. If the game were turned off half-way through a frame, you've got garbage - the player could be in the new map but in the wrong location in the black tiles surrounding the room, or in a new position but still somewhere on the old map off in the sea.
If the designers split up this process a little bit, and saved the party status at the end of a battle and then saved the player's position and current flags at the conclusion of every Nth out-of-cutscene step on the overworld, it'd still need to, say, keep a double buffer of the player's state in SRAM: a 'hot' page that's being updated, and a 'cold' page as the known-good-state for loading, flipping back and forth between them. That's ugly - but doable.
The simpler alternative is to not use SRAM for the live data, though, and only copy the relevant save data en-masse when it's safe/appropriate. The examples mentioned by Michael and Nick in the comments (SML2 and Pokemon TCG) sound like they do this on a per-level or per-turn basis. (One way a modern game would protect against incomplete-saving problems is to have the two (or more) save page system I mentioned before, with a master 'which page is good' bit that's toggled last, so when the whole save is written the SRAM indicates the old known-good page is still good, or the newly saved page is now good.)
There are two categories of reason that spring to my mind as to why Game Boy games have explicit save functions generally, which is the question you've asked in your title, and again they're not really related to the Game Boy.
One reason why games have save points / discrete save options is that user control of the circumstances reduces chances of a failed save as the game state is copied to SRAM. Handheld games can be interrupted unpredictably in several ways: by running out of battery, physical knocking of the cartridge, jolting of the system by attaching a DC adapter. If a save game were interrupted half way through its process, you'd end up with a damaged save state. Given that saving the state of a complex game can take noticeable time - and it's complex games that would usually have a save game capability - allowing the user to save on their own terms prevents errors. Six Golden Coins presumably just saves the list of levels that have been completed. It can't be more than, say, 1 kilobyte. Pokemon takes noticeable time to save - it would add up if it occured at the conclusion of every wild and trainer battle. (Game Freak have said that the time requirement was one reason.)
This second reason is a bit circular, but I offer it anyway:
Game designs copy from one another and take things that were enjoyable or practical from existing games and incorporate them into themselves. Games from one console generation imitate those from the preceding generation, and those imitate board and tabletop games the designers knew or heard about. A lot of Game Boy games weren't sophisticated enough to need saving, and they were copies of their home console counterparts, and they in turn were ports of arcade games or adaptations of existing board or tabletop games.
Games in general didn't offer auto-saves yet because nobody had demonstrated a game design with auto-saving in a successful game of that genre yet. When a new game appears with a design that works in a coherent manner with the rest of the game and has few technical downsides (small save space (i.e. low cost in components), quick saves, error-tolerant/not error-prone), then other games will copy it.
Sonic 1, 2, CD and 3 are all very similar in gameplay and design: you go to the right and try to achieve a more difficult hidden objective along the way. CD introduced auto-saving with the Mega CD's save RAM, which was also in 3 with its internal SRAM.
(There is also a Mega Drive-specific technical reason why it probably wouldn't be a good idea for Sonic 3 specifically to have used the cartridge SRAM as normal RAM - there's a latch on the board that acts as a mapper, paging the SRAM into the address space in place of part of the ROM. While the SRAM is accessible, that part of ROM isn't, and the game has to be programmed to work around this. Also that SRAM is mapped in only on odd addresses, so it's not as straightforward as regular internal RAM.)
Why do modern JRPGs still have save points? Some even have save points -and- autosaving. :) I recall some old Apple II rpgs (maybe Wizardry?) which stored your party's status on a dedicated 'Party Disk' which was constantly written to as you progressed. If your party died, they were gone if you hadn't suspended the game and duplicated the disk beforehand. So to answer the inverse of your question: why would games -introduce- a manual save operation when auto-saving was already possible? It's because auto-saving is sometimes really annoying. :D
I've also thought of another possible reason which could apply: in order to develop a game that uses SRAM as working RAM, all the development cartridges used would have to be a more expensive variant fitted with SRAM or the game wouldn't run at all. Running a game with 'normal' SRAM saves on an EPROM cart with no SRAM will give you loading and saving errors, but you could still test the game/maps/music/assets freely. I'd conjecture that at least some development was done like this to save some money where possible.