I'm assuming you mean to push back in terms of reducing the quantity of full-system automated tests and increasing the quantity of lower level tests. I've been pushing the same thing at my organization for a little while, so I've got some anecdotal advice.
I think the test pyramid is the best place to start. You sound familiar with it, so I'd continue talking about that. If you need more background on it, Martin Fowler wrote a good article about it http://martinfowler.com/bliki/TestPyramid.html
Recently I've been trying to ask people what they think the purpose of different types of tests are. If you have a reasonably decent test pyramid, you essentially know that your application is functioning correctly. So then, what are the automated UI tests actually testing? In my experience they're mostly testing that the application was deployed/installed correctly and is actually running.
Another concept I really like that goes along with this is Depth of Test. If you're doing all or most of your testing through the UI it's not possible to have any useful focus to your tests. This reduces the usefulness of your tests because when one fails it's not immediately obvious what caused the failure.
Along with this I like to say that the usefulness of a test decreases exponentially with the time it takes to run. This is more related to how often a test runs and less about the execution time of the actual test although they're usually related. Unit tests are very useful because they run quickly and developers are used to running them. Integration tests should run fairly quickly such that the barrier to a developer running them pre-checkin shouldn't be very painful. Maybe they don't want to run them every time they compile. Automated UI tests, especially a lot of them, take on the order of 10s of minutes, so you don't want to run them that often, if at all. This makes the test less useful because the feedback it provides is significantly disconnected from the actual change it's supposed to be testing.