Thanks for raising this @SJohns
I agree that there is a need for something around this. I did a lightening talk at the IATI members' assembly to highlight experiences of how people can get "confused" during the conversion and validation process (warning: contains cats!)
Over at the 360Giving data standard, we've worked hard to support organisations to publish spreadsheets (via templates), which can then be "easily" converted to the JSON format (360 is JSON rather than XML) via such tools as CoVE. In this context. it has felt like a smoother process to publication, as organisations are able to control and publish data in a format they know - which is particularly important in smaller places where there is litlle or no IT support/infrastructure.
Of course, it should be noted that no process (imho) can ever be "super simple". Even with 360 there are a few gotchas. We've all been down the date formats in windows / excel rabbit hole!
We should be minded that IATI has lots of one-to-many relationships: a typical activity will have multiple transactions at the very least, but perhaps also more than one participating-org, document-link, sectors and possibly geographies. When we get to results, then this starts to get more complex - multiple indicators with multiple time periods for reporting targets and actuals anyone?
As you state, this starts to make more sense when in a workbook. It should also be worth flagging some of the efforts around this already. I made a version of 2.01 (warning: this isn't fully tested) and added the files here. These files provide "user friendly" titles for the various parts of the IATI schema, which is your point about the mapping to the standard. Indeed, with Bond we provided guidance about working with such files, "flattening" them to a CSV, and then running through CSV2IATI to mint IATI XML. I'd agree that this isn't "super-simple", but it was interesting to see some organisations adopt this approach, once initial support / training / explanation had been given.
There's another school of thought which we should flag: "messing" around with spreadsheets can lead to inefficiencies and data quality loss. Outputting IATI XML data in the right and valid format should not be anywhere near the frontline. We've seen many organisations produce IATI data via teams working together at their strengths - with IT controlling the data production end. I just wanted to flag this, as no matter how great a tool is, it could be argued that solutions are better sourced in-house, within processes and systems already in place. That's a whole other discussion though!
That said, at Open Data Services Co-operative, we will start to work around some of this in 2017. We're not ready to announce timelines just yet, but will be testing how the various libraries and tools we have can address these user needs, starting with our own work. We will, of course, share our thoughts along the way.