Why didn't the RBF specification include additional constraints on the replacing transaction, such as that it would need to contain the same outputs (with at least the original output amounts) as the transaction being replaced?
Because it is not as effective to do this. What you describe is known as First Seen Safe RBF (FSS-RBF). However this imposes additional restrictions on transactions that make fee bumping difficult, if not impossible to do.
FSS-RBF notably requires spending an additional input. However if no input is available (e.g. user has one input, or is sweeping their wallet), then the transaction cannot be replaced. Or users may wish to retain their privacy by avoiding to spend certain inputs together and so if they have no inputs they are willing to add to the transaction, then it cannot be replaced.
Furthermore, this increases the size of a transaction with each bump thereby taking up more and more block space for little utility. The cost to continuously bump a transaction's fee also will grow non-linearly. In addition to the new feerate you are targeting, you also have to pay for the input you've just added at that feerate.
It also means that continuously bumping the transaction fee is annoying to do, and eventually, impossible (due to lack of inputs). If you lowball the fee, then decide to bump it later, and that is still too low, to bump it again requires another input. And so on and so forth. Bumping the fee like this reduces your future ability to FSS-RBF transactions too as you will be consolidating inputs.
Conversely, Full RBF does not require extra inputs, so as long as you have a change output, you can keep decrementing that to get the new fee. This means that the fee will only grow as the fee rate grows, and it does not require more block space. Since it does not require more inputs, you can fee bump transactions when you have no additional inputs available.
Couldn't this have made it safer to assume that zero-confirmation RBF transactions would eventually settle on-chain?
No, in fact, it would have made it worse.
To assume that a 0-confirmation transaction is safe means that you are willing to spend its outputs. In that spending transaction, you will be explicitly referencing the txid of the transaction whose output(s) are being spent. Replacing a transaction (in both RBF and FSS-RBF) means creating a new transaction that spends the same inputs, i.e. a double spend. This new transaction will have a different txid because it, at the very least, changes the amounts of the outputs and thus results in different data being hashed. So if the bumped transaction becomes confirmed, then any transaction the spent the outputs of the lower fee transaction instantly becomes invalid. This is not safe at all.
The fact that people will think that unconfirmed transactions are safe to accept if FSS-RBF were used (as you did) is far more dangerous than Full RBF. With Full RBF, people know to just wait for confirmations. With FSS-RBF, people will think that unconfirmed transactions are safe to accept, spent its outputs, and then find out that their transaction is invalidated when a bumped version of the original unconfirmed transaction is mined instead. It is a false sense of security.
In general, unconfirmed transactions are not safe to accept, regardless of RBF, FSS-RBF, or no RBF at all. Either way, an unconfirmed transaction could be replaced with a conflicting one and result in any transaction that spent from the original unconfirmed transaction to become invalid. Because the dangers are all the same regardless of RBF and which type of RBF is used, Full RBF where any outputs can be replaced is better as it is more space and fee efficient.
There is some discussion of the motivation for Full RBF over FSS-RBF in BIP 125 itself.
