The extremely short version: smaller tests, because they run smaller parts of the system, naturally constrain what the programmers can write, and so this creates an opportunity for sharper (easier to notice/harder to ignore) feedback. Let me add that this doesn't necessarily lead to better design, but instead it rather creates the opportunity to notice design risks sooner.
First, to clarify, when I say "microtest" I mean "a small test" and nothing more. I use this term because I don't mean "unit test": I don't want to become embroiled in debates about what constitutes a "unit". I don't care (at least not here/now). Two people will probably agree more easily on "small" than they would on "unit", so I gradually decided to adopt "microtest" as an emerging standard term for this idea.
Bigger tests, meaning tests that run bigger parts of the system in their "action" part, tend not to criticize the design as clearly nor as completely as smaller tests. Imagine the set of all code bases that could pass a given group of tests, meaning that I could reorganize the code and it would still pass those tests. For bigger tests, this set is bigger; for smaller tests, this set is smaller. Said differently, smaller tests constrain the design more, so fewer designs can make them pass. In this way, microtests can criticize the design more.
I say "more harshly" to conjure up the image of a friend who tells you directly what you don't want to hear, but need to hear, and who yells at you to convey urgency in a way that other people might not feel comfortable doing. Integrated tests, on the other hand, stay quiet and only hint at problems mostly when you no longer have time nor energy to address them. Integrated tests make it too easy to sweep design problems under the rug.
With bigger tests (like integrated tests), programmers tend mostly to get in trouble through sloppiness: they have enough freedom to write tangled code that somehow passes the tests, but their understanding of that code fades quickly the moment they move on to the next task, and others have undue difficulty reading the tangled design. Herein lies the risk in relying on integrated tests. With smaller tests (like microtests), programmers tend mostly to get into trouble through over-specification: they over-constrain the tests by adding irrelevant details, usually by copy/paste from the previous test, and in so doing they relatively quickly paint themselves into a corner. Good news: I find it much easier and safer to remove extraneous details from tests several hours or days after I write them than I find it to pull apart tangled production code months to years after I write it. As mistakes go, over-specifying does more and more-obvious damage quicker, and the alert programmer sees earlier that they need to fix things. I consider this a strength: I notice problems earlier and fix them before those problems strangle our capacity to add features.