Yes that is the ideal situation for Unit tests
To look at a different situation - if you are writing software that will not be changed in the future then perhaps you could consider skipping the tests. I have yet to work with such software of course :) Also TDD and BDD proponents would argue that even in those cases you should still use those techniques. They treat testing as an essential and critical part of the design process rather than than the more traditional 'verification checking' approach used for testing.
Units tests area should be proactive, built-in way to make sure the code works and can be changed in the future without breaking it.
So if you truly practice TDD and write the tests before the application code that makes them pass in order to make the tests drive the implementation then skipping tests is not even something that will happen. If, however, tests are written to meet the 'minimum coverage % level' and are written after the app code then their value is reduced and the quality will suffer greatly.
You may think that you will have time to write unit tests once the product settles down. This is a very common fallacy and will usually meet reality when you ask the product manager for a few weeks to write tests and not be implementing features... Such a statement will usually not work well and in my experience, that practice never happens.
It's worth repeating that - IT AIN'T GONNA HAPPEN
If features are changing frequently, that is precisely the sort of situation where unit tests are a programmers best friend, making sure they don't break stuff despite the high churn of change.
Think of tests as a programmers most valuable tool and one that should not be avoided.
I consider manual testing very valuable in all cases but I do consider 'unit' tests to be automated by definition. This means you can have extensive manual testing without Unit tests existing, i.e. development before 2000 :)
One final note on software that never changes - one example is software that goes on-board space vehicles - wanna guess if they test that? (see Mars Climate Orbiter for an example of what was not tested appropriately. Oops.). So we have learned to test that sort of never changed again software quite a lot.
Separate testing from development and you separate quality from the act of creation