Did I miss in the article exactly why your developers needed the warnings set off? The implication is that they were trying to account for bad data. Would the workaround have actually caused problems in your specific case? Maybe they weren't running a COUNT but rather a SUM where the NULL being dropped out is not an issue.
In the case where there are nulls for a column that is used for aggregates wouldn't the underlying issue be that the column should not have been designed to allow nulls in the first place? Was the ability to "fix" that design flaw in their power or were they just trying to work with what they were given?
I am not an apologist for lazy developers but in my experience it is common to find "gray area" reasons as the cause for such workarounds - meaning the fault is not fully on the person doing the workaround.
When I first saw this title I immediately thought of an SSIS package failing because of the warnings being interpreted as an error. This is where I've seen the need for turning warning off come up at my work. In our case there has been no ill effect because the queries that caused the warnings were evaluated for ill effects.
A nice thing to add to this article would be a mention of this SSIS issue and how it can be mitigated so that we can at least stamp out that little enclave of "lazy" devs.
FYI - this MS Connect issue states that the SSIS issue was resolved with SQL Server 2012: https://connect.microsoft.com/SQLServer/feedback/details/483175/failure-because-of-warning-about-null-aggregation%5B/quote%5D
Basically, there were aggregations being done as part of nightly jobs which spanned COUNT, SUM, MIN and MAX operations. The problem was that the team monitoring the servers kept reporting the warnings as "errors" (being of the mindset that anything reported by the server unless it contains the word "success" is bad).
The development team could not prevent NULLs because in the system, NULL were actually valid values (e.g. revenue not reported v/s a zero revenue). So, allowing NULLs in the system was not a flaw - it's by business design.
My intention in preventing the team from switching ANSI_WARNINGS to OFF was because doing so opens the door to generation of potentially bad data.
On the SSIS angle, yes it was an issue in SSIS for SQL 2008. However, the team switched from DTS to SSIS from 2012 and hence did not encounter issues there.
Thank-you for your time and sharing your valuable feedback!