I find the first party SDK is likely to work without a lot of trouble but boy do you find people have weird ideas like "I don't know anybody who develops web sites who doesn't use .NET" or "it's no problem that it takes developers two hours to get up and running with our SDK even if they can get up and running with our competitors in five minutes".
It's fair to put a timebox in for a first party SDK and it ought to be a short timebox like 15 minutes because a bad SDK written by people who don't really care if it works properly can steal 15 hours from you pretty quickly.
I've experienced both of these -- Good SDK that save you time over the raw API and bad SDK that steals your time. In fact, sometimes both are created by the same organization targeting different platforms!
I don't think you have any hard and fast rules about this you have evaluate each product and each situation individually.
Yeah, have had to switch to home made sometimes because the SDK for instance didn't use connection pooling, and the server on their end was slow setting up new tcp connections.
Or that they have opaque logging in their own weird format and don't properly hook into a common log interface, so don't know what's going on inside the SDK. Which is bad if it's a big component of the app you're making.
It's fair to put a timebox in for a first party SDK and it ought to be a short timebox like 15 minutes because a bad SDK written by people who don't really care if it works properly can steal 15 hours from you pretty quickly.