Also, the Add Attachment opened a file dialog (instead of a Workspace
dialog) suggesting attachments would be expected to live outside Jazz
source control.

It seems like the requirements for requirements can go from one extreme to
the other.

"Type 0"
At the short end of the spectrum, nothing more than the "description"
paragraph of a Work Item is needed. There is no requirement captured
anywhere else outside of the work item. You could even fake some things
using workitem linking, tagging, composition, etc.

"Type 1"
Increasing in complexity (and flexibility), you have "real" requirements,
separate from the work items (at which point the description field of the
work item is redundant?). But at the end of the day, it's similar to a work
item. They are not in SCM and are not versionable as you've pointed out.
Content is limited to styled text and whatever attachments you want to
create, which you then have to download to view. This is what Jazz supports.

"Type 2"
In my opinion, you're talking about the next level of
complexity/flexibility. Some document is in "source" control, and at some
point, somehow, a work item refers to it as its "requirement".
There are real advantages to working with documents in an eclipse workspace,
and shared via SCM. In some cases, you have to do it anyways because you're
using some Eclipse-based tool to author the requirement. But this is a
significant increase in complexity, similar to the difference between using
just "Description", and using Requirements. And just like graduating from 0
to 1, biting off 2 should be optional.

BTW, I'm new to Jazz and haven't had much experience with formal
requirements (be it Jazz or otherwise), but I enjoy pretending otherwise.