As the designer of above mentioned timeline editor application (Audacity) - there's a distinction to be made between application state (gets saved automatically/to your preferences) and project state (gets saved with the project). It's tricky to decide whether view (or even - which part of a view) belongs to which.
For audio editors, I'd want to make a distinction between view stuff that happens in the project area (track height, timeline settings, waveform vs spectrogram, etc) and view stuff that happens elsewhere (language, toolbar configuration, workspaces, etc). I'll get into the why a bit further down.
Con: If my only change since my last save was to move the playhead or change the zoom level, then it seems strange to be warned that I have unsaved changes when I close the file.
The same thing is true for your undo stack: you don't want every selection change and zoom event to be its own item in the undo stack as that'd make it pretty cumbersome to actually undo anything.
As for the undo stack, you can roll view events into project events, so for example "Import -> zoom in -> trim -> scroll view" would have the zoom and scroll steps rolled into the project events and undoing would set your project and view into a previous state. This behavior makes sense for view events which directly affect stuff within the project area/viewport, toolbar layouts not so much. Audacity does this "rolling multiple changes into one event" all over the place, perhaps even too much in some cases.
You can do something similar for saves - changing the view alone wouldn't need to prompt a "do you want to save?", but the view could be saved together with actual project changes.
What do other applications do?
As an example for another app, Blender is of the opinion that everything view-related belongs to the project, so all your workspaces, current viewport rotations and such are stored in the project. This does have the advantage that I can return right where I left off, but when I send that project to someone else, they will see what I last worked on - and given the customizability of blender's interface, they might be completely lost as to where the menu/button/sidebar/view went they're used to seeing in their setup. Even opening my own old projects, I tend to get somewhat irritated because the layout is different to my default layout these days.
Are there standard conventions around this? Will users expect a certain behavior here?
As for conventions and expectation, this depends on your target audience. If you're targeting users of one specific DAW or editor, it probably makes sense to take on some of their terminology and conventions where they make sense. You don't really get brownie points just because you found a unique solution to a problem that's solved well everywhere else.
That said: If your target audience is explicitly not industry veterans, there's very little point in emulating anything existing. Audacity for example is still using the tape recorder model quite extensively, hence why options about playing and recording are called "transport". Or why there is a workflow where, in a stopped state, you hit pause first, then record, set your levels, and then unpause to record something.
So when I look for conventions to follow, I don't actually look in other DAWs first and foremost, but in programs our audience actually is familiar with - browsers, smartphone apps, text editors, etc. And it's especially when looking at Google Docs, Microsoft 365 and Figma, I realize:
Maybe "just" automagically autosaving everything is becoming the new expectation, and warning on close is becoming pretty old-fashioned. (I don't think our field of audio/video editors is quite there yet, but I expect we'll get there this decade.)
