What additional considerations are there for dual-funded payment channels? Naively, it seems like a dual-funded channel should not be much more complicated than a single funded channel; You'd just have an extra input from Bob and it would be reflected in the balances of the first commitment tx. 

I'm guessing dual-funded channels are more complicated though, since it's not currently specified in the BOLTS.

Is it because for a dual-funded channel there is the additional risk of one peer not sending over their signature for their input to the funding tx? Presumably this would force Alice to either wait, or consume their input in another tx in order to invalidate Bob's dual-funded funding tx. Is that an issue? And if so is there a solution for it?

Are there any other complicating factors for dual-funded compared to single-funded payment channels?
The issue of waiting for signatures also holds true in the single funded channel. 
Let us assume Alice wants to open a single funded channel. As long as she has not gotten signatures for the commitment transaction via commitment_signed message she cannot publish the funding tx.
In the dual funded case there need to be two rounds of signature exchanges (one for the input of the funding tx and one for the commitment tx) but from a risk perspective of an unresponsive peer this is not worse than the situation we already have in single funded channels. 

The real difficulties emerge since in the case of dual funded channels it is not so clear who should pay the onchain fees and why (also there is some additional communication overhead (see below))? Remember in the case of single funded channels all fees are paid by the initiator in every case as it was the initiator who had the interest of opening the channel.

Let us look at dual funded channels: Some might argue that this is a service to the purchase inbound liquidity and there should be a service fee. This is discussed in this thread: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001631.html along this line goes the question and discussion of how to make sure that the channel is not closed again right away: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001532.html 

In general there was a nice post on the ML about the initial dual funded protocol. I can't sum this up to quickly but I guess you will find some of the challanges in the thread: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001682.html