I assume the OP intends for "verification point" to mean a condition whose evaluation determines whether a test fails, e.g. what test frameworks often call an "assertion".
When deciding whether the code under test is ready, all you may care about is a binary answer to the question, "Does every test pass?". For all other times, your tests serve two purposes, which I will call verification and diagnosis. Verification is checking whether the software meets its requirements. Diagnosis is narrowing down the specific conditions that cause a failure.
This duality is often a source of tension between testers and developers. If a tester does nothing else, they must decide whether a product passes tests. If a test fails, the developer, if nothing else, must change some code. In between those two events, someone must determine which of the many circumstances leading up to the failure were necessary and sufficient. Armed with that information, the developer will think about how those circumstances map to code. And before that, someone may need to think about whether those circumstances happen often enough or are important enough to justify making changes.
Browse the bug tracking system of any product and you will likely see evidence of the tension between verification and diagnosis. A developer bounces a bug back to the tester because the symptoms are "too vague" or "not specific enough". A tester, having spent a great deal of time reproducing a problem, wonders why a lazy developer can't diagnose a problem for themselves.
So how does this apply to automated tests? Using multiple verification points in a single test increases its diagnostic value. If I need for f() to return true, g() to return 1, and h() to return 3 in order for a test to pass, the developer will appreciate knowing which of those three conditions failed.
There are other reasons for using multiple verification points. Sometimes a test will include "sanity checks": conditions that might point to bad assumptions in your test (e.g. availability of a resource) rather than problems in the code under test. You may also use multiple verification points because the setup expense justifies performing multiple tests at the same time, although doing so may reduce a test's diagnostic value. (In reality, we make this compromise every day; most of us do not rebuild our entire test environment for every test.)