Productivity is influenced by a number of factors - organizational culture, experience with the language and tools, knowledge of the project, specifics of the process being used, outside factors such as regulations, and capabilties of the team as a cohesive unit. This is why, when estimating projects, the most useful data is that of the specific team that will be conducting the work. As you generalize to organizational, industry, and then throughout software projects, productivity becomes a fuzzy area.
One of the advantages of iterative development is that you go through all of the phases many times on a single project, allowing you to gain insight into the process and the team. You might start with organizational data from past projects, but very quickly (2-4 iterations) get team-specific data for project planning.
The number that you cite (1-1.5 user stories per sprint) is the highest level of abstraction. The best time to use this number is when you have no industry-specific data from whatever domain your product falls in, no organizational data, and no team specific data - early on in your first projects using Scrum. It probably comes from teams using all kinds of variants of Scrum, including combining Scrum with other process improvement techniques (Kanban, CMMI, Lean). I'd trust using this number as it stands, since Mike Cohn and Mountain Goat Software are well-respected agile consultants. However, as soon as you have data from your organization (or, even better, your team), use that instead for planning sprints.