https://www.folklore.org/Signing_Party.html
So no "of course" about it.
Note also that Microsoft had a "no easter eggs" policy starting in the early 2000s. It's not really a Jobs thing.
There's a grain of truth to the grandparent comment but it is distorted by Occupy Wall Street ideology.
- the effects of it are clear
- there's basically no chance of unexpected side effects (I suppose in theory it could structurally weaken the case if the signatures were carved too deeply...)
- if a user stumbles upon it the intention is pretty clear and obviously harmless
- it's not something that might get snuck in without approval of senior management, because it's not hidden in that sense, so there is a limiter on how many of them accumulate and how complicated they might get
which help to explain why you might by policy forbid software easter eggs while still being an advocate for "signing your work".
What people will put up with in a hobbyist and small business environment is very different to what's acceptable in enterprise and beyond. It's all fun and games until someone has to sell to the US government...
Note that this was in the aftermath of a summer with multiple major XP security issues.
It was probably driven by the same kind of pragmatic business drivers as the later Microsoft ban, i.e. the perception by the market of how "serious" Apple was as a company.
---
Edit: According to Gizmodo in 2012:
> He justified the credits ban as a way to avoid headhunters and other companies trying to poach Apple engineering talent. At a time when Apple was sinking rapidly, he said that it made no sense to make the life of the competition easier. He also argued that they were all responsible of the stuff they created in Cupertino. This was a complete change from the 1980s.
It seems kinda harsh but it's important to remember the context: at the time, the security situation in Windows and Office was dire and it was (probably correctly) perceived as an existential threat to the company. I think "no Easter eggs" was as much for optics as for its actual effect on the codebase, a way to signal "we know about and stand behind every line of code that gets written; nothing is unaccounted for".