Isn't it simpler and just as effective to put the feature behind a configuration flag that is off by default and the user must manually turn on in the browser preferences? Both Chrome and Firefox already use this mechanism.
With a time-delimited system rather than a flag-delimited system, people con try things out without having to learn about flags. More importantly, they can set things up on a staging server or in a beta environment, then distribute the link to potentially non-technical stakeholders and testers without having to include detailed instructions on setting flags.
The hope is that this will lead to better feedback about medium and large scale deployment of new features, instead of only lone-web-developer feedback.
It would however introduce a lot of hassle in testing the feature - being unable to work on a particular branch for all of every Tuesday. A better approach might be disabling it for an hour or two daily at 4am local time, or for 5 minutes per-hour, etc.
I can't imagine asking users (either public or internal) to do that.
Last time I heard something like this discussed, one of the suggestions was "browsers automatically disable support for experimental features on Tuesdays", which should allow people time to experiment but should prevent them from depending on it in production. Also, it's a simple rule that can be shared through the web development community by word-of-mouth[1], and many browser vendors can share it without having to coordinate infrastructure, etc.
[1]: Obviously this wouldn't be the only way to share it, but when one developer can turn to another and say 'why doesn't this work' and get a one-sentence answer that contains an accurate model for predicting future occurrences, it's a lot more likely for that model to be reliably propagated via Stack Overflow, Twitter, the random mailing-lists-reformatted-as-web-forums content farms that crop up in search results, etc.