> Only if one accepts the slippery slope fallacy that they'll eventually remove the "No unsigned code" option.
Not at all, for several reasons. First, defaults are powerful things. The vast majority of users never change them, or even become aware that they can be changed. This remains true even if you throw an unskippable dialog box right up in their face -- lots of people will just blindly click "OK" to accept whatever the default in the dialog box is, without stopping to consider the alternatives. The result is that default settings tend to become "the new normal," even when they're sub-optimal.
(Example: why did IE6 rule the Web for a decade, despite being demonstrably inferior to the alternatives for most of that time? Because for nearly all users, it was the default.)
This seems especially true in the case of this particular preference, for two reasons. First, it's a technical question ("what's 'unsigned code?'"), which means many users will avoid changing it for fear that they don't fully understand the consequences of doing so. Second, it involves security, and users have been trained that in questions of security departing from "standard operating procedure" puts them at risk, so others will avoid changing it for fear that doing so will expose them to new vulnerabilities.
In other words, it's not unreasonable to expect that offering unsigned code will quickly become an infeasible strategy for OS X developers, even if users still have the option to accept such code. The option may be there, but those developers will find themselves marginalized simply for being something other than the default.