Point 2 is reasonable argument against the use of the given approach.I worked on something similar where user can have data in different form depending on the entry point.Obviously,complexity of your code is going to increase as per the number of new flows you introduce but depending on benefits involved sometimes you have to add new user flows.If you do not have use cases with insanely high branching factor,you can easily manage complexity if you focus on few things.

Try to **make things readable** at each level.Whether you are exposing your API or writing code,keep everything meaningful both for your programmers and API users.If you take care of readability,smaller things like naming etc.,things will become less complex.

**Do not rely on data patterns** in your storage expect a few key fields,you will have to be careful while defining what is you always going to have.For example,you have created your API assuming,you will always have this field filled by the user but then you introduce a new use case where that field is not mandatory.You might have hard time changing your code for that.

**Follow standard coding principles** that our elders have been teaching us like KISS,SOLID,design patterns etc.This one also includes my first point but that has been mentioned separately because that is the worst thing in a complex scenario.