Pagination works better for several reasons:
Because the resulting HTML isn't complete, some browsers display NOTHING, while others display what comes back. So, browser compatibility would be one reason.
Because with pagination, Google can place sponsored ads at the top of each page; with infinite scrolling, that's more complicated to do
Because with infinite scrolling, the server (google) is still doing work, even though the user might not be doing anything. With pagination, it is guaranteed that the user wants more data, because the click next page; with infinite scrolling, the server is still providing data, and there's no reason to think the user will be consuming that data
Because infinite scroll is a horrible memory pig
On the flip side,
With infinite scroll, the only benefit for the end user is that they do not need page navigation to find what they want: everything's on the page, and simple CTRL-F can help them hone in on something. This trick does not work with pagination.
Other than that, I don't see much benefit to infinite scroll.
EDIT: Sorry, can't address all the comments without making a million comments myself, so I'll include them here, as they are relevant to the OP's question:
If you google "trump", Google will report "about 755,000,000" results were found. Of them, only 12 are displayed. The user's only requirement is, to keep asking for more. That list of 755M results is residing somewhere on some Google server, but is not downloaded to the user's browser. That's because pagination is used.
With infinite scrolling, there are several implementations of it. Some is pseudo "infinite", where there are blocks (larger than a page; perhaps, 2 or 3 pages or more) which are privately downloaded and displayed a page at a time by the browser, and as the user scrolls down near the bottom of the block, another block is downloaded and displayed line by line or page by page. This gives the appearance that the list is infinite, and is a very common implementation.
Another type of infinite scrolling is "true" infinite scrolling, whereby the server, in this example, flings all 755M results to the browser. Here, the server determines the method to display:
Which method is employed depends a lot on the type of data being served up. For Google, the potential to fling down 755M results means that managing that on the browser would cause a huge amount of network traffic to result, as well as crashing most browsers as the amount of data becomes unwieldy. But divvying up that 755M results is also unwieldy for Google, and is wasted effort since few people or systems will consume that much data. So Google more efficiently manages that data by privately storing only 128 of those results on its side, and divvys up that data into blocks of about 14 pages. The user sees 10 pages, but you can slide to the last page (page 10) and then see an additional 4 pages. You'll also note that the query has resulted in "Page 14 of about 128 results", not "Page 14 of 62,916,667 pages in .98 seconds"
Other forms of infinite scrolling don't involve that much data, but definitely more than a few pages: a news source, for example. US News and World Report today has 100 articles: it displays only 4 or 5, and in the background has downloaded about a dozen; you scroll down consuming that dozen, and when you get close to the last page of a dozen, another dozen or so is downloaded - all the appearance of infinite scrolling - this is the pseudo variant. There aren't 755M articles, but there are well over 100. When you get to 100, you can make a hard click to get more articles, and the process repeats: I gave up after making 10 "load more" clicks, suggesting there are well over a thousand results (indeed, the age of the articles are showing to be several months old; the implication is that the articles might go back as far as their repository contains).
An example of true infinite scrolling serving up all results that pauses the browser as the last of the HTML is waiting to be received would be a client connecting to a site containing limited amounts of display data: an email client, an FTP client, or a music or photos page. There, the amount of items displayed might be expected to be no more than, say, a few hundred items, and so, that particular site might decide not to implement expensive libraries to manage the display. Other sites, like Flickr, for example, which does serve up images, has determined that many of its users have more then just a few hundred images, and so, they will implement a more robust pagination library.
And therein lies the answer: performance vs functionality vs cost. If Flickr went on the cheap and decided not to implement fancy pagination, anyone using their site would walk away as their browsers crashed and burned as the wait time (or memory usage, or both) became too cumbersome. Question is, are you willing to implement an expensive pagination library (or roll your own) to keep your users happy? What is your ROI? How much time do you have? What features to you need to expose to the end user? What server resources do you have? Will your results result in even more data being displayed?
As to that last question, here's a consideration: Google serves up only text. So you scroll and scroll, you see nothing but text. Suppose you served up images, like US News and World Report's news thumbnails, or Flickr's image thumbnails. Now your users are not only downloading the relatively small HTML representing an image, but, once downloaded, the browser has to independently download the actual image - that may come from another site like an advertisement. So the user's wait time to download data your server is serving up, but it also must further download user-friendly content. With infinite scrolling, that is a consideration for you: even background downloading of your data must necessarily include downloading content, which could be audio, photo, or video.