I know it has happened to you in the past; however, in the latest version, you are now able to "retry". By saving settings again, it re-queues the hung rebuild task. If the task still does not complete, it is important to check your logs for associated errors.
While investigating this report, I found a bug in vBulletin where retrying actually saved the wiki into a disabled state, rather than the desired state. This could be corrected by re-enabling after the task succeeded. However, this bug did not affect XenForo at all. This is fixed in the next release.
While investigating this report, I found a race condition, where the temporary-disable during the retry is not re-enabled, if the retried task ends up completing after the retry is submitted but before the retry is committed to the database. The timing for this is very unlikely, would require a PHP execution timeout of more than 60 seconds, and would require a MySQL connection timeout of at least the same. This is fixed in the next release.
While investigating this report, I found a different bug: a retry is not even attempted if the only setting you change is the Wiki Active state. In this case, a failed deferred task is ignored and the wiki is re-enabled anyway. This could lead to data sync issues, but it means that it was possible to re-enable your wiki at any time (as I was able to), provided you only changed that one setting, and provided that a deferred task did not later complete for which you had specified a wiki-disabled state upon completion (that is, left the Wiki Active state unchecked while changing a different setting). This is fixed in the next release.
While investigating this report, I found a bug which might be what you are experiencing. When changing a setting that requires a rebuild, the wiki active state is changed, as normal. While this is still occurring, you might alter setting on a page that does not contain the Wiki Active box. The new rebuild is queued after the previous rebuild, but now thinks that the current active-state is disabled (it is, because of the existing rebuild) and to preserve that (which is wrong). When all rebuilds complete, the active-state is therefore set to disabled. In order to correct this issue, a separate setting must be used for rebuilds that affects the active-state without actually altering the Wiki Active setting. This is preferable to having a deferred task pass the active state to the next task, because a hung task with the desired state would not pass the state to the new task. By always preserving the original state in the setting value, we can show the correct state on the settings page, include an appropriate notice, and provide a status checker for tasks that affect whether the state is actually being applied to visitors.
While developing the above fix, I found a different bug which only has a negative effect in vBulletin. When changing a setting that requires a rebuild while the active state is disabled, the rebuild is never marked as completed. Thereafter, when trying to save the Wiki Active state as enabled, the state change will never succeed (in 4.0.20 it will succeed after 60 seconds have passed), because an open task is detected.