The tier-bound organization runs the risk that decisions will be made based on who will implement them rather on where they should be implemented. For example, design a feature so that the major part of the work will be done in tier X, even though it naturally belongs to tier Y, since the tier Y team happens to have much more workload than the tier X team. These decisions might be correct business-wise, but they still incur technical debt and the project-bound organization can usually depend more purely on technical and architectural reason when making these decisions.
On the other hand, the tier-bound organization has an advantage since contrary to intuition - the borders between projects should be less strict than the borders between tiers. The interaction between tiers should be strict and depend on clearly defined protocol, and having separate teams implement the sides of these interactions force the teams to keep the protocols strict and well defined.
The borders between projects should be less strict since they share code, and sharing code is less dangerous than sharing data. If some code was useful in tier X of project A, it's more likely to be useful in tier X of project B than in tier Y of project A. I mean - how many JavaScript functions from your one-page framework are going to be useful in the database? A tier X developer working on project B might be familiar with that code since they've seen it in project A. A project A developer working on tier Y of the project might be familiar with that code since they've seen it in tier X - but they wouldn't be able to reuse it in tier Y anyways.
Data, on the other hand, must be shared between tiers of the same projects, and since sharing data is dangerous you need more strict borders. Here's where the separation of teams can be beneficial - if the desktop app could use access to some data from the server for a quick and dirty solution, a project-bound developer might be tempted to give it that access(since these programmers control both tiers), but a tier-bound developer will have to request that access from the server team, which are more likely to say no(since they have less need for that particular dirty hack so they are less inclined to corrupt the interface to support it) and force the desktop developer to seek a more proper solution.
Project separation is less important in this regard - there is far less need to share data between projects, and when there is such need it's often done through another tier(e.g. two smartphone apps talking through a server), and even when it's done directly, you need to give very little damn to screw this up with dirty tricks, since the border between projects is clearer than the one between tiers.
