Just to give a little background first: Bitcoin uses a so-called UTXO model. You own UTXOs (or "coins", to give an analogy). Every coin has a value (which can be any number of satoshis) and has an owner (script) "stamped" into it. Every transactions "melts down" a number of existing coins, and "forges" new coins. The value of the new coins cannot exceed the value of the melted coins. The difference between the amount melted down and the amount forged is the fee of a transaction.
This means that the protocol really no concept of a "balance". There are just coins. You can have 3 BTC in your wallet, consisting of a 1 BTC coin X and a 2 BTC coin Y. These can be stamped with the same script (address) or not. It doesn't really matter - a wallet can consist of many addresses.
So say you want to pay 1.5 BTC to someone else, who has given you address A. Your end goal is creating a transaction that consumes the 2 BTC coin, and produces a 1.5 BTC coin (to the payee) and a 0.5 BTC coin (minus fee) back to a new address of your own wallet (called a change address). It's also possible to consume both the 1 BTC and 2 BTC coins, and outputs 2x a 1.5 BTC coin. Let's assume that's what you're doing.
How would you do this using the Bitcoin Core RPC? There are a number of ways:
The most automatic way
If you're using Bitcoin Core's built-in wallet (i.e. the Bitcoin Core wallet is what created the addresses involved, and it manages your coins), you can make it do everything. Just do:
bitcoin-cli sendtoaddress <A> 1.5
Where <A> is the recipient address. It will automatically determine which of your UTXOs to use, and create a transaction that spends those, pays <A> and creates change, then sign the result, and broadcast it on the network.
Manually but using the wallet still
If you want more control, you can perform the things sendtoaddress is doing one by one yourself, allowing you to observe the intermediary results.
The first you do is create a raw transaction that pays <A>, and nothing else:
bitcoin-cli createrawtransaction '[]' '[{"<A>": 1.5}]'
It will report a hex raw partial transaction with just that one output, and no inputs. Next you want to add inputs and change. You could do that manually (see further), but you can let the wallet do this for you. This is what fundrawtransaction is for.
bitcoin-cli fundrawtransaction '"<output from CRT>"'
This will give you another unsigned raw transaction, but now one that includes inputs (sufficient to cover the 1.5 BTC you're trying to send) and change (for whatever is left of the inputs spent after subtracting 1.5 BTC, plus a reasonable fee based on network estimation, and estimation of how big the transaction will be after signing).
Then you sign it, and broadcast it.
bitcoin-cli signrawtransactionwithwallet '"<output from FRT>"'
bitcoin-cli sendrawtransaction '"<output from SRTWW>"'
The advantage of this approach is that you can inspect the intermediary results at every stage (using decoderawtransaction amongst others), or make many changes to the process. Perhaps you have a multisig wallet with another device - and you need to make a pass by there doing another signrawtransactionwithwallet (or whatever equivalent that other device/software has for working with raw transactions).
Fully manual
If you want the most control, you can do everything manually - including the ability to include inputs that don't belong to your own wallet. This is the example you gave in the question, but if that's all you plan to do, you're much better off using one of the previous two methods.
As you pointed out, you first need to gather a list of UTXOs that can be spent. This can be done with listunspent, but you can also include other UTXOs - including ones from other people if you're participating in a CoinJoin transaction for example.
bitcoin-cli listunspent
Then you have to construct the (full) raw transaction, including the inputs you want to use from before, the output to the recipient, and including a change output back to yourself. If you want that change to go to you own wallet, you can use getrawchangeaddress (which is like getnewaddress, but will treat outputs to it as change rather than an incoming payment). You also need to manually estimate the vsize of the transaction will be after signing, determine a fee to use based on that (the block space market prioritizes transactions based on fee per vsize), and subtract that fee from the change you're creating. This is a bunch of work, and mistakes are easily made.
Next you'll need to sign the transaction. If you have the private key in your own wallet, you can use signrawtransactionwithwallet like before (note that signrawtransaction from your example no longer exists; it has been split up into signrawtransactionwithkey and signrawtransactionwithwallet). If not, you can either use signrawtransactionwithkey if you have the private key, or you could transfer the raw transaction to other devices/people, and sign there too.
Finally you'd use sendrawtransaction just like before.
Using PSBT
At this point I need to point out that all the raw transaction based transaction APIs have been superseded by the PSBT-based RPCs (see BIP 174). If you try to use the RPCs above you'll notice they really only work with simple scripts, and you need to pass a lot of information along everywhere. In particular, signrawtransactionwithkey will need information about the UTXOs again, the scripts used in those, what type of scripts they are. This is pretty painful, and easy to screw up.
PSBT is an interchange format for transferring/storing partially signed transactions, along with any information signers or other participants may need to be able to sign. It'll convey UTXOs, script information, information about the keys in it, ...
The equivalent of "manually but using the wallet still" would be:
walletcreatefundedpsbt instead of createrawtransaction + fundrawtransactionwalletprocesspsbt instead of signrawtransactionwithwalletfinalizepsbt to convert a fully-signed PSBT to a raw transactionsendrawtransaction like before to broadcast the result.
The equivalent of "Fully manual" would be:
createpsbt instead of createrawtransactionwalletprocesspsbt instead of signrawtransactionwithwallet. There currently is no equivalent for signrawtransactionwithkey, but PSBT is supported by various other pieces of software (most notably, HWI which allows PSBT signing and other operations with hardware wallets.- Again,
finalizepsbt and sendrawtransaction like before.
PSBT has a lot more utility functions, such as combinepsbt (mostly for multisig), joinpsbts (for doing CoinJoin-like things), decodepsbt and analyzepsbt that can tell you what to do next, utxoupdatepsbt to gather information from the UTXO set and add it to a PSBT file (which works even if your Bitcoin Core wallet is not involved), etc.
TL;DR
You can use a workflow with or without fundrawtransaction. If you don't use it, you have more manual control and aren't forced to use the Bitcoin Core wallet itself.
