Explicitly separating requirements will make it easier to design the right system.
With nonfunctional requirements (I prefer the concept/term quality attributes - should provide new insights beyond functional vs. not functional), you are more concerned with the properties of the software rather than the functionality. That is how the system performs some function, not simply what the system does. Quality requirements have a significant influence on the architecture of the system in ways that the functional requirements do not and for this reason they should be treated differently.
Keeping the quality attributes separate from functional requirements allows you to analyze, specify, and prioritize different kinds of requirements in different ways. For example, quality attributes are normally specified using a quality attribute scenario while functional requirements might take the form of stories, use cases, shall statements, or any other number of formats. Most of the systems I've worked on had less than a dozen quality attributes and many, many more functional requirements.
I would actually introduce another kind of requirements - technical constraints. Again, explicitly separating the requirements into these three buckets gives you cues for how to make the right trade-offs while building the system. Functional requirements are often quite negotiable, quality attributes will heavily influence your architecture and the structures you choose, technical constraints are non-negotiable.
If this were my team, I would tell them the requirements should be clearly annotated by type to make sure we don't miss something important in the architecture. Think about the architectural drivers, not just the functionality.
Anthony Lattanze in Architecting Software Intensive Systems: A Practitioners Guide gives a practical overview of architectural drivers and why they should be treated differently, much more comprehensive than my summary here.