All these comments on PM not knowing tech(being dev before) is bad - come from folks measuring stuff from #volume of features shipped, which is a very service sector mindset, where delivering stuff is all important.
Well PMs are hired to move metrics, not to release features - which anyone can co-ordinate or project manage.
For the kind of user facing consumer or b2b products most jobs are - the tech understanding needed for the PM is enough to speak on behalf of dev team in a room without devs to push back and set expectations right against- the marketing head who thinks launching a V2 of the web product should be doable in 10 days right.
So there's an example quoted about Data Science projects - well boss if say you are in content feed pod at a startup and your DS model or any set of interventions doesn't improve engagement metrics then about time when everyone gets canned.
The above are thoughts on the importance of PM roles in non feature factory or delivery only teams. If you are delivery team PM then it's just a fancy label to get more applicants to a project management role.
Now addressing OPs point on timelines - boss the onus falls on you to communicate. You have to explain why it will take Y time instead of X and justify or suggest ways to cut scope and still meet X timeline. You will get a push back, you reply again taking the new points, again you get some new expectation that's much better than before - guess what it is called - negotiating at work. This is something everyone does at work weather across pods like product<>engg or within teams between your manager<>you on tasks assigned. Other person will never know what you know better and need to communicate.
If you dear confronattions that come from negotiations then not working on it will not take you much ahead in places where collaboration is key.