A major version of Esprima is released (and published to npm) only when there is a breaking change. Typically, this happens when Esprima parser needs to support the most recent ECMAScript specification (final version, not the drafts). Since ECMA-262 switched to an annual release, Esprima major version bumps tend to follow this as well.
Language tools which intentionally (often with an explicit experimental warning) want to understand a new proposed ECMAScript syntax, even before the syntax is finalized in the official specification, can not always wait until a new major version of Esprima is available. To support such tools, the development version of Esprima should be published to npm. As an additional bonus, it gives a bigger window of opportunity to give feedback before the stable version of Esprima is released.
This could be done using the --tag feature of npm publish.
A good precedent to follow is the daily development versions of TypeScript, they are available as 2.2.0-dev.20170201, 2.2.0-dev.20170131, etc.
For Esprima, I propose that we make it even more explicit that this is a bleeding-edge version. For instance, the tag could be in the form of 5.0.0-unstable.20170201.
I think dev, unstable, and canary are all good choices, and glad to see this happening!
Additional data point: sometimes a consumer also adopts the bleeding-edge version by themselves. For instance, WebKit's Web Inspector wants to support dynamic import and hence it grabs Esprima from master (see https://trac.webkit.org/changeset/211554).