> If there is actual slack in the schedule, they will tend to increase scope (i.e. address tech debt, quality of life improvements, plan better).

If all your engineers will make use of most of the slack for such purposes, rather than unproductive activities, you've either been very skillful or very lucky in hiring them (or at least their team leads, etc).

A lot of engineers (myself included) will produce more if there is at least a moderate amount of pressure applied towards delivering something useful relatively soon.

Too much pressure can definitely have the reverse effect, as it introduces more long term technical debt than what is saved in the short term. Also, intermittent period of low pressure can lead to innovation that wouldn't happen if the pressure is always constant.

Still, most tech teams I've worked with will tend to become a bit too relaxed (leading to shorter days, longer breaks, more chatter/social media, etc) if they are presented with delivery dates 1 year in the future for tasks that "feel" like it's only going to take 3-6 months.

Which may very well lead to the task taking 15-18 months instead of the 10-12 months it really takes due to those unexpected complications nobody explicitly thought about.

This also transfers to "agile" development, and in many cases "agile" can make these issues even worse, especially for deliverables that require months to years of effort before anything economically self-sustained can be released. (For instance, if you need to replace a legacy system, the new system isn't delivering net benefit until the legacy system can be shut down.)