I assume based on Sonic's background that Usenet support will be good, but in a nutshell, what can I expect in terms of newsgroup availability, speed, retention, and so forth?
I stopped reading Usenet in 1998. You're a braver soul than I...
I have no information on the Usenet experience with Sonic. Sorry!
A problem I'm having is that my ISP stopped offering an SMTP server of its own.
I run my own MTA, so I don't use Sonic's. (BTW, I confirmed again and again with Sonic that it was OK to run an MTA, before I signed up. It really is OK, even on a consumer-grade line. They really don't mind. Really.)
I assume that Sonic's outbound MTA is sane. I've never had to use it.
Some of the FAQ pages on Sonic's web site mention port 25 blocking, and they say you need to contact Sonic to get it turned off for your account. This wasn't the case for me; I never had anything blocked to start with. I suspect the FAQ is just out of date. If by some weird chance you *do* find something blocked, I am 110% confident that Sonic will be able to un-block it for you.
I also want to know if I can expect any issues with restricted ports, throttling, or anything that doesn't give me full access to what I expect as a typical (in terms of everyday Internet activity) user.
Absolutely no issues here. My impression is that Sonic doesn't fold, spindle, mutilate, shape, or otherwise mess with your packets. If you send an IP packet to some destination, it will get there unaltered. If someone sends you a packet, you will receive it unaltered. No matter if it's a SYN or not, or what port it's on, or whether it's TCP or UDP.
I caught my previous ISP (well, two ISPs ago by this point) messing with my traffic one time where I kept getting "connection reset by peer" on long-running ssh connections. I had a tcpdump going on both ends (my end, and the remote end). Pings were going continuously. At a certain point in the log, the keepalives from my ssh session were received by the other end, and ACKs were going back... but the ACKs were never being received. Whereas the pings (of a similar size) were going just fine. Eventually the first end gave up and sent a RST, and *that* got there just fine.
I considered that (the other, non-Sonic ISP's) behavior to be unconscionable. They were classifying traffic differently based on what TCP session it was part of. That means they had enough packet inspection hardware chewing through my packets so that they could even *tell* what TCP session it was part of! That is digging deeper into traffic than it's an ISP's job to dig.
Sonic has never done anything like that to me. Not to my knowledge, anyway. I guess it's possible that Sonic is just doing a really good job of staying undetectable about it, but Occam's razor says they're just not doing it, period. They treat their job as just to get packets X, Y, and Z from point A to point B. And they seem to do a pretty darn awesome job at it.
Something that you didn't mention is reverse DNS. Reverse DNS with Sonic is self-service; you don't have to provide a list of PTR records to tech support, you just log into the Member Tools section and set them yourself. It's a bit less geeky than RFC2317-style delegation, but it works and it doesn't involve any CNAMEs.