1. With regards to “Best of Breed” fallacy, I think many would agree with you that local optimisations can often have a negative effect on global system performance. An example that I can recall that is similar to your 255 characters example. I remember reading about Lee Iacocca (from his auto biography) about his observation that Ford shipped 2 cars per rail cart. After some measurements, he then went back to the engineers and asked them to make the cars 2 cms shorter. The end result was that 3 cars could now fit into one rail cart. A 50% increase in throughput by taking 2 cms off the length of the cars.

2. With regards to architectural design considerations, communication between all the stakeholders is the biggest challenge (IMHO). With good communication the technology often develops over time to a satisfactory level. The vertical slicing approach; I would classify that as a communication strategy rather than a technology strategy. A bit like a special ops unit within the army, a smaller group that moves faster and has a reduced stakeholder set to answer to. Such an approach gives local optimisations but I don’t think you can win a war or feed an army(/enterprise) with loosely coupled sets of special ops groups.

I am more inclined to favour an enterprise architecture approach. There are many, but I like some of the thinking behind the Zachman Framework and it has stood the test of time. Having a taxonomy that maps business strategy down through an organisation and into IT infrastructure helps everyone sign from the same hymn sheet.

P.S. I am admire your posting frequency - well done

It's not always possible to go that way though, for organisational and political reasons. One such reason is the "best of breed" mentality (really lowest common denominator) approach to the design where the technology choices (eg, Java dev and mainframe dev) and team choices (eg, different consultancies or different geographic locations) preclude one team handling all the layers in a vertical slice. This means you end up with layered teams. Even in this case it is still worth aiming for vertical slices (all teams working on the same slice of functionality at the same time) but methodological differences, differences in goals and difference in development speeds between the teams in different layers can make this very difficult or even impossible. This is the situation you want to avoid!

Disadvantages? Main one is code duplication, where the same problem is often solved by various developers repeatedly. While it's an obvious inefficiency, it's not much of an overhead often.
Imagine horizontal slicing. A service consumed by Team1 and Team2 is developed for them by service team. If Team1 needs to change it later, it needs to go through endless consultations with the service team and Team2 on changing the service. Often it's too much of risk to change and too much of a regression testing to be performed, hence, a BIG NO to any change.
In vertical world, Team1 just changes it and that's the end of it. While not pure, it delivers real life results for business.

And if service isn't working, it's affecting particular part of the application developed by Team1, not a range of features developed by many teams.