Jantje:
I see this has been implemented in 1.5.4. The sd library uses the src folder and as such is incompatible with my plugin.
I assume our arguments have not been heard.
Can someone of the core Arduino team confirm this?
If your request is to remove the "arch" folder, then the answer is no
(btw, it was already done and planned right before I noticed that this discussion was going on).
The basic point is that it's confusing to have multiple versions of the same library.
Like, say, take a library that communicates with an external display, say adafruit, just to name one, makes a library that talks to it, and they also provide an optimized version for AVR that uses hardware SPI (or whatever).
If someone else optimizes the library, for example for pic32, I'd rather have them get adafruit to merge the pic32 optimization into the adafruit library, instead of making a new pic32 display library, and in this case, I feel like having separate folders makes it easier, because adafruit can just grab the arch/pic32/ folder straight from the other person and make them responsible for it as opposed to having everything in one folder or one file, which makes it harder to coordinate. Also, adafruit can improve the common part of the library by touching the code in src/*.cpp folder, providing better graphics algorithms for example, that everyone can benefit.
Using a single folder, or #ifdefs within a single file, makes it harder to provide versions of a library for multiple architectures, not easier.
I repeat, this is not a tech matter, and you will face the same problem, even worst, with a single src/ folder, because it requires more work from the original maintainer to include your code.
That's exactly the point of the arch folder. Or maybe you have something else in mind?
Jantje:
Also from a user perspective removing a library is removing 2 folders.
The user remove just the Servo folder that contains both Servo/arch and Servo/src (and all the others files).
Jantje:
It is not a real burden but it is work that moves from the compiler to the tool. I realize this is not a problem for the Arduino ide but it is one for other tool builders.
We should make things simpler for users (and library authors in this case), and this makes life harder for tool's author (both tools and Arduino IDE developers).
BTW this time is just a little more harder, I'm sure you felt much more pain when you faced the auto #inclusion of libraries, or the sketch preprocessing, no? 
Jantje:
My main objection is that the source is not under the source folder. The source is actually in a subfolder of the arch folder and the declaration is in the source folder. That is at least for the new architecture dependent libraries.
The architecture independent libraries (and I feel this is the biggest bulk) will have there source under the src folder.
You can have source code in BOTH arch/ and src/, the difference is that in src/ you will put only architecture-independent code.
For example the Ethernet lib has a common src/ with all the supported protocols, and various SPI implementation that are architecture specific.
The Stepper library is a completely architecture independent library, and have no arch/ folders at all.
Jantje:
Think about this situation: Paul is working on a architecture dependent library and he is doing the teensy part.
I do the avr and sam part. and you are the owner.
Paul delivers 1 file Platformdependentlib.cpp for teensy
I deliver 1 file Platformdependentlib.cpp for avr and sam.
How will you organize this? Will you copy my file to the sam and avr folder? Will you ask me to deliver 2 files?
I would ask you to provide two file for arch/sam and arch/avr folders, instead of one full of #ifdefs. In this case Paul becomes responsible for arch/kinetis and you for arch/avr and arch/sam. When I receive updates from you, I need to just copy your file straight in their specific folder.
In any case what's the alternative you're proposing? putting all the architecture in one big file? In this case it seems more complicated to merge your patch (because it actually needs code review) and probably I'll give up.