In modern web applications, elements on the page may come into existence as a result of actions that the user may take, or they may disappear from the page as a result of actions that the user may take. In order to test modern web applications in the browser, it is rare that tests do not have to wait for some condition or another to be true or false before the test can proceed properly.
In general, there are two kinds of waiting in automated browser tests. In the language of Watir, these are "wait_until" and "wait_while". If you are not using Watir, you have probably already implemented similar methods in your own framework.
My experience is that wait_until type methods are more prevalent than wait_while type methods. Your test needs to wait until a field is available to fill in, then it needs to wait until the "Save" button is enabled after filling in the field. Your test needs to wait until a modal dialog appears in order to dismiss it, then it needs to wait until the modal dialog is gone before the test proceeds.
But wait_while style methods are still important. Your test may wait while a spinner is on the page. Your test may wait while an interim message like "Processing..." is on the page.
And of course there are variations and elaborations on these. A sometimes useful method in modern Watir is "wait_until_present" which waits until an element on the page is both visible and allows interaction.
These methods poll the page over and over again (typically multiple times per second) for a set amount of time until the condition they are waiting for is true before allowing the test to proceed. I often call these "polling waits" as I think that is a better description of the actual function of the wait. Polling waits are far and away your best choice for handling situations where elements on the page that your tests depend on come and go in response to actions in the pages.
But sometimes a polling wait just does not work. Web pages can do strange things, and while it should be somewhat rare, simply stopping your test for some number of seconds may be the best thing to do.
For example, your web page may kick off a data update of some sort on the back end of the system for which there is no notification. While it may be appropriate to have the test issue API calls until the data update is complete, it may be more convenient simply to have the test sleep for a short time.
Or it may be that the condition you would wait for is so ephemeral that you can't capture it in order to wait for it. In this case, a one- or two-second sleep might be appropriate.
This is hard to explain, but from time to time I have seen web pages that will for example briefly manifest an interim page or otherwise cause faulty signals from the browser, and then you can see Selenium try to find an element in the wrong DOM. On rare occasions you may want to have a test sleep while the server decides what the DOM presented to the user should be.
Prefer Polling Waits, Keep Sleep Waits Short
In general, it is best to prefer polling waits over sleep waits. On those occasions when you are forced to use sleep waits, I find that a good rule of thumb is to have sleep waits of no more than one or two seconds, maybe three seconds under difficult circumstances. Sleep waits of small duration will not hurt the performance of your test suite too badly. And of course you should take regular passes through your battery of tests to refactor sleep waits to polling waits whenever you can.