The YP Hash has still been a huge pain, it's hard to explain to new clients, and new SHOUTcast users why it sometimes fails to create, or sometimes just stops working for whatever reason and will make it so nobody can even listen untill they fix it or switch to private server.
if it fails to create with the current v2.2.1 DNAS, it won't block listener connections. that was only something with the v2.0 builds and was done with the best of intentions i.e. to make it obvious something wasn't right, but as you note, it caused more issues. hence v2.2.x being made more v1.x like.
I have created a video to assist them but many still have problems, mainly they use in valid characters in the description field.. it's just a lot to do for some, I just recommend they do not even use it and leave it disabled... if they want listeners they can list in TuneIn or iTunes. This is one thing SHOUTcast 1 did well -- it was either listed in the director or it wasn't
where possible the v2.2.x DNAS will auto-create it, but so many streams are not correctly setup or have junk put in their source software for titles, etc that the DNAS will not attempt to make an authhash if it means that if listed listeners would not be able to easily find it or it'd cause issues (e.g. 'my station name' is a generic station name that is intentionally blocked).
yes v1.x is simpler in that manner, but when having to wade through the crap it puts in the system (bad genres - which get mapped to 'misc', wrongly encoded title update and a whole slew of other issues), something which blocks that i think is better. sure it'll annoy some people but the whole thing with being listed is to give listeners the best experience to find you and if a station cannot care about such things, then it's probably better they aren't listed / broadcasting.
and the whole point of the authhash is to act as a fixed piece of data about the stream(s) so they will be reliably listed (once the authhash is created) and that they can maintain a static station id (which is not possible with the v1.x DNAS) and that means you don't have to keep updating the station links if the IP of the DNAS changes (which is why we advocate people using DNS names for the stream servers which the v2.2.x DNAS far better supports than what the v1.x DNAS could do). and it also means that you don't have to necessarily rely on the information for the stream being correctly done in the source software as it can be managed via the DNAS instead and i don't see how that's anymore different than signing up to tunein or other services to get listed.
as fundamentally it is there to help resolve the issues present in the v1.x system and i know people don't like it, but the v2.x system resolves the core issues with how the v1.x system works (preventing against incorrect clustering and simplifying the YP implementation for v2.x listings) allows for doing all of the location / country filtering which people demand from the API we provide but with a large number of people still using v1.x DNAS, it's just not worth enabling that API feature, despite it doing what is being demanded.
and yes there are somethings which could be done better with the authhash implementation from the start (though authhash disappearing from confilg files has to be due to an external issue or from the v2.0 release), but there's not much else i can think off and for what it does to improve the SHOUTcast platform capabilities vs the downsides, they are just not comparable. and i know people will still keep using the v1.x DNAS, but no one supports that version of the DNAS anymore (anything from Radionomy will be v2.x based and AOL long gave up on the v1.x DNAS) and it's not like it's not already possible to relatively easily hack into a v1.x DNAS which with all of the things like heartbleed and open security vulnerabilities against the v1.x DNAS, i'm shocked people refuse to update a 7-8 year old version (and there are people out there still using v1.8.x builds of the DNAS!).