UInt is a common cause of bugs. It is very easy to accidentally generate a -1 and wind up with infinite loops or similar problems. (Many C and C++ programmers have learned the hard way that you really should just use int unless there's a need for unsigned.) Because of how Swift manages type conversion, this is even more important. If you've ever worked with NSUInteger with "signed-to-unsigned" warnings turned on (which are an error in Swift, not an optional warning like in C), you know what a pain that is.

The Swift Programming Guide explains their specific rationale in the section on UInt:

NOTE

Use UInt only when you specifically need an unsigned integer type with the same size as the platform’s native word size. If this is not the case, Int is preferred, even when the values to be stored are known to be non-negative. A consistent use of Int for integer values aids code interoperability, avoids the need to convert between different number types, and matches integer type inference, as described in Type Safety and Type Inference.

Here is a possible explanation (I am no expert on this subject): Suppose you have this code

let x = 3
test(x)

func test(t: Int) {
}

This will compile without a problem, since the type of 'x' is inferred to be Int.

However, if you change the function to

func test(t: UInt) {
}

The compiler will give you a build error ('Int' is not convertible to 'UInt')

So my guess is that it is just for convenience, because Swift's type safety would otherwise require you to convert them manually each time.