I don't think it's the fear of pushing to production on day one, but that a day one employee would not yet be able to produce anything worthwhile enough to push.
A very well tested codebase with resilient systems and tooling takes time to learn, it will take time for a person to become productive within it - and that time is a lot longer than the 4 or so hours you get on your first day after the legal paperwork is done ;)
So pushing on day one - regardless of dangers it poses to the system - seems like pushing to production for the sake of pushing to production.
On another note though - I've worked at companies that have adhered to best practices and done remarkably well with continuous deployment and testing, but the risk of a pushing code to production is never zero. The intent of testing and resiliency is to reduce the odds of catastrophe and increase your confidence in your systems - not to make you overly cavalier.
At my current job, we aim for a new employee to push to prod on day one not because we want the employee to begin churning out valuable work immediately, but because we want them to quickly become familiar and comfortable with the development, QA, & deployment workflows and tools.
The ticket that gets deployed is often as simple as a typo fix or a small CSS tweak, just to illustrate the whole process. The risk of deploying to prod isn't zero, but since we deploy many times a week already, the risk of deploying a typo fix is pretty low to us.
It also serves as a test for the existing employees: ideally those workflows are smooth enough that it all Just Works on a freshly-set-up environment and account, and we are comfortable enough with our rollback strategy that (after reviewing and testing) we are not afraid of merging in and deploying our new employees' code.
A very well tested codebase with resilient systems and tooling takes time to learn, it will take time for a person to become productive within it - and that time is a lot longer than the 4 or so hours you get on your first day after the legal paperwork is done ;)
So pushing on day one - regardless of dangers it poses to the system - seems like pushing to production for the sake of pushing to production.
On another note though - I've worked at companies that have adhered to best practices and done remarkably well with continuous deployment and testing, but the risk of a pushing code to production is never zero. The intent of testing and resiliency is to reduce the odds of catastrophe and increase your confidence in your systems - not to make you overly cavalier.