G.degree is the only reporting view that doesn't have the dict-like methods: keys/values/items
So G.nodes.values() and G.edges.values() and G.adj.values() all work as you would want.
G.degree didn't get the full treatment, but it could.
To answer your questions:
1) dict(G.degree()).values() certainly works for both nx-1 and nx-2.
For nx-2, it returns the as [d for n,d in G.degree()] but I'm afraid that list comprehension won't work on nx-1 because G.degree() returns a dict. Perhaps better and backward compatible is
deg = [len(nbrs) for n,nbrs in G.adj.items()]
We strongly considered that and len(G.adj[n]) as the way to get degree info for nx-2, but in the end made a reporting view G.degree.
2) Yes it's possible to introduce values() to DegreeView. But would there be a better way to get what you want? Is there a use for values() other than degree distributions?
To be dict-like, the G.degree view would iterate over nodes... That's a little silly. Who would want that over iterating over G. To get the (node,degree) pair iteration you'd have to do G.degree.items(). It seemed natural to have iteration be over the (node, degree) pairs. And lookup makes sense with G.degree[n]. We don't really need anything else (do we? -- well clearly we might want values() :).
G.degree is not a full dict-like object... In fact it breaks dict-like iteration -- and I think it should.
3) Yes, it is worth adding something to the migration document -- whether we decide about the values method.
Thanks!