I generally agree with the points raised in this article, however speaking with direct experience (we have build chains with over 100 builds) there are areas of TeamCity that could be improved to make build chains more effective and easier to navigate.
Source code consistency is good, but enforcing it too strictly can also lead to substantial inefficiencies. For example if a build modifies and check-ins code, a new build chain is triggered, even when all the information is available within the build itself for the next step in the build chain to continue.
We have a few dozen .Net projects referencing other components via NuGet and one of the steps in the build is to verify and potentially update these NuGet references, when this happens (and this could happen several times a day) we have TeamCity to check-in the updated *.csproj and packages.config files so that everyone gets the updates via NuGet restore, and in doing so a new (and unnecessary) build chain is triggered occupying valuable build time.
Having a way for TeamCity to identify and override the default behaviour in these special cases would be definitely welcome.
With regards to the Build pipelines view, I don’t think the Snapshot dependency list view mentioned makes it that much easier to see the status of the builds in the pipeline as it requires frequent scrolling up and down and opening the logs of failed builds to try to figure out the order of the dependencies.
A way to improve this in my opinion would be to group builds under the same project in collapsible panels, with a simple green/red indicator for each build and an overall status. “Green” project would then be shown by default collapsed, “Red” projects expanded, greatly reducing the “noise” on screen.