Some mechanics don't play well with reloadable save anywhere. For example, some games have items that produce some useful effect, but have a chance of breaking. (Examples include Wizardry 1-5 (4 is especially worth looking at here), Bard's Tale 1 (except the remaster unless "chapter differences" is enabled in Legacy Mode), and Dragon Quest 2+ (Prayer Rings restore MP to the user but might break with each use; no other item is like this).) With reloadable save anywhere, you can just save, use the item, and if it breaks, reload. (Note that, in Wizardry 4, the player is sometimes expected to do that; there's a penalty to saving in that game (the enemies on the floor respawn), but it doesn't matter if you just changed floors.)

There's also gambling situations (earning money through something like blackjack is much easier if you can just save state and reload), and other RNG-heavy segments (SaGa Frontier 2's final army battle is notoriously difficult, but if you use save states, it ends up suddenly becoming much easier).

Those would all be examples of the designer not balancing or designing the game well, and making us suffer for it, while seeking an easy way out.
Think about it, if the player is doing those actions that you are suggesting and (according to the designer) that's not "how the game should be played", and that somehow "breaks the game", then that means your game was designed badly, and broken. If a player is save-loading to bypass annoying restrictions, the solution isn't to restrict saving. It's to fix the problem at the source.

Also, some games with gambling minigames have a "memory" across savegames, so that stops any sort of using savegames to bypass gambling RNG. I'm not saying I think that's a good solution, but it is an interesting idea. Again, if the player feels necessitated to use the save system to bypass the hassle of "winning money", your gambling minigame is likely not very fun.

Except that, even with that solution, it might still be possible to manipulate it. Given that the RNG seed is saved, someone could just take advantage of foreknowledge of the RNG and play accordingly; games like blackjack are much easier if you know what cards will be dealt.

Significant reliance on RNG is bad. And if the player can use reloading to make it work in their favor, why not allow it? Point should be to let the player play the game, not set up a certain challenge, even less so a randomized one, that all must get over in a way intended by the devs.
There's such a thing as the registry...

Only on Windows, and many people (including myself) consider the registry to be a mistake.

Was actually wondering how Linux handled that. And it's a way to store settings that doesn't care about file permissions. Separate settings files for each program in its folder does seem like a better solution, the old .inis on Windows, but you run into that same permissions issue, plus the possibility to have multiple instances of a program open battling for access to that file and/or overriding each other.
Either way, back on topic, in that case go with what phaolo said, however you do it. Default save path, but make it standard, which can preferably be altered even in the installer, and then changed in settings or, if the devs want to make it for advanced users only AND offer the instructions in the manual or readme, don't just leave it for people to figure out on their own, store it in a text settings file and let people change it there, the issue in this latter case being that they'll need to move their saves manually too, while a setting should do that for them (at least copying, in case the previous save folder doesn't have write access for the deletion). And check for write access and if the set path doesn't have it, give an error and revert to default until/unless fixed.

Typically, on Linux:
* System-wide settings are stored in /etc, which is only writable by root. (Normal users can read most of the files in the directory, but there are a few, like the one containing password hashes, that are only readable by root due to security issues.)
* User settings have traditionally used dotfiles, which are files whose names start with a period; the "ls" command will skip over such files by default (apparently originally a bug in early UNIX "ls", but that was then treated as a feature); those files are stored in the user's home directory.
* The modern way to do this for user files is to store them under $XDG_CONFIG_HOME, which defaults to ~/.config (where "~" is a shorthand for the current user's home directory).

I'm trying to think and don't see the logic. If adding a feature (saving anywhere and reloading without restrictions) breaks the game, how does it mean that the game is initially broken?!

The ideal save system is save anywhere, anytime, no restriction, no question asked.

Anything more restrictive is most of the time an artificial restriction used to hide game flaws.

There's some common cases, like during combat in games with modal combat, where save restrictions don't feel so artificial. Thing is, to actually implement saves in such a game, the developers would need to code in access to the save feature, and would need to write code to save and load the combat state, which would otherwise not be necessary. More code means more bugs, in addition to being more work on the part of the developer.

Also, in a game like Dragon Quest 1, is it *really* necessary to allow saving during a battle? (Then again, there's also a good technical restriction for not having save anywhere in that game; it would make the passwords longer, as that game did not already have a battery backup. With this said, this argument applies to the rest of the series and to much of the Final Fantasy series, as well as to most JRPGs and some (mostly older) WRPGs.

There's also some menus where it doesn't make sense to save, like on the title screen and load save menu, or on the save menu (which would lead to recursive save menus, which a player could use to try to overflow the stack), or (for the vast majority of games) pretty much anytime the player is already in a menu. Or, for that matter, saving in the middle of a load screen might not be practical.

(Yes, some of this might seem pedantic, but some of this (namely the modal combat situation) is not.