There are a few cautions: 1. Feature discoverability, 2. Icon interpretation in the absence of labels, and 3. Confusion over which state the toggle (or stateful button) represents.
1. Discoverability: Out of sight, out of mind
Lukew, in 'Obvious always wins', cites loss of engagement when vying for menu space:
His mobile example involves lots more space tradeoffs than the desktop app case you refer to.
While the toggle menu looked “cleaner”, engagement plummeted following the change. The root cause? People were no longer moving between the major sections of the app as they were now hidden behind the toggle menu.
2. Decoding icons can be challenging; more so when only one is visible at a time.
You had two icons which users had to decode. There are no text labels to assist the user.
Now you have one icon. This means you have a memory tax. The user has to remember:
- What the currently visible icon means (without hovering over it)
- What the previously visible icon was (and what it means)
3. Does this icon represent the current view (the state) or the one I wish to change by selecting it (the intent)?
If you compress the two view controls into one button, you have a couple issues:

Alan Cooper discusses this further in About Face, which he refers to as 'flip flop buttons':
The problem with flip-flop controls is that they fail to fulfill the second duty of every control - to inform the user of their current state. If the button says ON when the state is off, it is unclear what the setting is. If it is OFF when the state is off, however, where is the ON button? Don’t use them. Not on buttons and no on menus!