IMS/QOS on LTE is actually a very complicated topic, as it goes beyond routing/QoS rules. I'll try and comment on some of the points you hit on.

So to clear up a few things:
1. They assume all sip traffic must by their own, and route to their IMS Core
IMS SIP proxy information is relayed to the device when it attached to the network if it's IMS capable. It's up to the devices stack to use the proxy provided by the network, which as far as I'm aware no 3rd party software does at the moment.

2. Is Verizon using separate APNs for their voice and data.
Based on http://support.verizonwireless.com/clc/devices/knowledge_bas... it appears they may use vzwims
I believe by convention, for roaming the "ims" APN is to be used, however, I'm having trouble locating the recommendation by either the GSMA or 3GPP, so now i'm not sure where I heard that.

3. routing/QoS rules that are rather nongranular
Actually, LTE has spent immense effort in providing capabilities and controls around prioritizing very specific traffic. In high level concept, when you use the IMS core to generate a SIP call, the local SIP proxies will have links back to the PCRF (policy server).

The PCRF is capable of generating IP Source/Destination rules that are sent to the network, to prioritize the specific RTP conversation. This is taken to the level in LTE network's, where the LTE network depending on the rule will "Guarantee" the bitrate is available, and the rule is pushed to all aspects of the network include the eNodeB (Cell Site). The over the air scheduler in the eNodeB is to respect the QoS rules to ensure traffic such as conversational-voice does not receive jitter/packet loss from background traffic (such as file transfer). Obviously, if you don't use the IMS core, you lose this capability, since it's not based on packet inspection, but by the proxy server itself knowing a call is in progress, and creating dynamic QoS rules just for that call.

Even with the way net neutrality is going, from my view it looks like the standards body is providing the capabilities for a fairly QoS rich environment. Personally I don't have a problem with, the network understanding that your doing web browsing, and to deliver a better experience, you get higher network priority for you're basic web viewing, then the person down the street who's doing background file transfer, and saturating the cell site. The net neutrality problem is, if the carrier tries to leverage this not for experience, but profiteering, or to block certain types of traffic. However, that's a much larger debate that I don't think belongs here.

4. Paying customer voice traffic should not have to compete for resources with your data traffic
This is effectively true already (see number 3 above). However, your point is more around that this is reason to block non-carrier SIP, which isn't the case. As an operator, I can just lop it in with the rest of the background data traffic, and you receive a user experience that matches.

Since this is background data, there is also less of a guarantee that the service will work consistently, as it's not something explicitly tested for or verified in the many pieces of network infrastructure. As is indicated in other posts, this sounds like issues with the ALG, however, there are all kinds of things that can go wrong, NAT, Firewall, IDS.

I once worked a problem with RTCP/RTP a number of years ago, where a bug in one of the network elements, actually got confused by the STUN packet, because it was being too smart and setting up rules based on inspection of RTCP. The funny thing about it, was that everything would've worked fine, if it wasn't being too clever to try and solve the problem for us.

*I do work in the telecom industry, however, my views and comments do not reflect my employer in any way. All information here can be found publicly when knowing where to look, or is my own opinion.