Transaction fee are currently fixed (around 0.002 XMR/kB) which is penalising for small transaction (0.026 XMR/TX). Buying an item for 0.2 XMR incurs a transaction fee of 13% which I would call confiscatory.
Still cheaper than Bitcoin :) But yeah, they're high.
A transaction fee that is a percentage of the transaction (say 0.1%) would go a long way to improve user-friendliness.
Please no. Why should someone with more pay more fee? He costs the network the same in terms of bandwidth / storage, and the only difference is the value of some bits in a transaction. Also, you can't really enforce this because you don't know the amount being transacted in the first place. If you just set it as default an trust the sender to follow it, it would kind of leak the amount being transacted, which we really don't really want.
Is there no method to prevent spamming other than setting a minimum absolute amount of fee?
Some PoW just to submit a TX could work as well, but then why would miners bother to include TX-es in a block? Might as well mine empty ones. But, our problem with fees has other causes, and needs some adjustments, I believe. We have dynamic block size and dynamic minimum fee. Now, this is a dynamic minimum fee, so you expect it to be cheap, but at the present it's not really, so why is this?
Non-RCT TX-es could be 1-2kB, so that means 12x to 6x lower fee/TX. For those, both formulas worked well. You could squeeze 30 TX-es in a block, if there's demand in the mempool you could make it 31 and have a 3.3% increase which would easily be covered by even the min. fee. However, a 20% increase in block size would not be economic for the miner, unless people paid multipliers of min. fee. This is designed only for peak times. If there's organic growth, that cheap 3.3% increase could make block size slowly creep up. If you study the 2 formulas, you will find that this would also make the min. fee you pay per TX slowly decrease.
However, introducing RCT made a one-time bump in TX sizes, but the formulas were not changed together with this. Now, you can squeeze only 5 TX-es in a block, and if there's some demand, adding just 1 more TX means an increase of 20% in block size, which comes with a big penalty! It acts as a kind of wall which makes it hard to kick-off block size dynamics. This is the source of the problem. There was one proposal to address this by tweaking some parameters in the dynamic formulas, which ought to bring the min. fees down and fix the relations.
Edit 2017-06: The above problem was fixed in the April HF by increasing the min. penalty-free blocksize to 300kB, and it will be further alleviated by reducing TX size (estimated to 50%) with range proofs optimizations bringing TX size/penalty-free blocksize down to 2.3% from the above 20% which was the root cause of issues.