I'm basing this primarily the assemblers I've used -- primarily MASM, NASM, and (to a lesser extent) TASM. Some of the later versions of TASM had (have?) some features to support OO, but I haven't used them much, and I'm not trying to comment on them.
First: most languages have moved toward a structure that's at least somewhat tree-like. Whether object oriented, or object-based, or exactly what, there's quite a bit defined about the relationships between different parts of a system. There's also quite a bit to "protect" one part of a system from accidental "meddling" but other parts (even though the protection can usually be bypassed if you want to). By contrast, assembly language is relatively "flat" -- most of the relationships between the code (and data) in different parts of the system are established primarily by documentation and to a lesser extent naming conventions.
The result of this is that it's often much easier to couple code much more tightly than would be ideal. The requirements that drove the choice of assembly language to start with (higher performance, smaller size, etc.) often reward this as well -- by bypassing approved interfaces and such you can often get code that's smaller and faster (though not usually a lot better in any dimension). The language and tools themselves do much less to restrict what you do (good or bad), which places a much greater burden on the managers to prevent problems. I wouldn't say it's qualitatively different, but quantitatively it is -- i.e., management has to work to prevent problems either way, but in the case of assembly language it generally takes more (and often tighter) guidelines about what is or isn't acceptable.
Mitigating this is largely a matter of more careful guidelines, more guidance from more experienced personnel, and more specific, carefully enforced naming conventions.
Staffing is something of a problem. The problems I've encountered, however, where not primarily the ones I expected. Finding guys with a bit of a "fighter jock" personality who were happy to jump into assembly language code was fairly easy. Most did quite a reasonable job, despite an almost total lack of prior experience in using assembly language.
The difficulty I encountered was in finding more senior personnel -- people who could keep the project under at least some semblance of control, and weren't completely accustomed to languages that would provide (and largely enforce) the guidelines necessary to keep the code reasonably maintainable and understandable.
Looking back, I may have been/caused some of the biggest problem in that respect. I can see two sources of problems on my part. First, by the time of the project I'm thinking of, I'd been coding primarily in higher-level languages for quite a while, and using assembly language only as a last resort. As such, when I did use it, nearly every possible trick to gain performance was not only fair game, but expected. Second, back when I had worked on some systems written entirely (or primarily) in assembly language, it was under some rather iron-fisted project managers. At the time I'd been relatively young, and quite frankly resented the way they'd run things, so tended to do the opposite. In retrospect, what they were doing really was important, and not done just because they were old and inflexible (which, I'm pretty sure was how I saw things at the time).
non-[PC|web|enterprise]programming, where Assembly is predominant or very popular. I'm talking micro-controllers, industrial automation or robotics. Sure, there are high level languages in these areas too, but you see Assembly a lot.