There isn’t a hard-and-fast rule. That’s because one of the fundamental tenets of API design is making your callers’ lives as easy as possible by giving them an interface that takes the kinds of values they’re likely to have on hand.

Your example has parallels to C’s memcpy(dest, src, n) function, which copies a range of memory n bytes long starting at src to a range of n bytes long starting at dest. Most of the function’s callers will be copying a primitive or data structure whose size in bytes can be determined using the sizeof operator:

some_structure src;
some_structure dest;
memcpy(&dest, &src, sizeof dest);  // Easy to understand

Had the function been implemented as memcpy(dest, src_start, src_end) (where src_start and src_end are pointers to the first and last bytes in the structure, the caller would have to do a lot more gymnastics to figure out where the source structure ends:

memcpy(&dest, &src, ((void *)&src) + sizeof src - 1);  // Harder to understand

What doesn’t work well for memcpy() might work very well for functions that do counting. If you know your callers have upper and lower range bounds in hand, it’s much better to give them count(int from, int to) than count(int start, int how_many):

int lower;
int upper;
count(lower, upper);  // No gymnastics

…versus…

count(lower, upper-lower+1);  // Gymnastics

Even if the innards of count() need to know the number of iterations, it’s better to calculate it in one place (inside the function) than force your callers who have upper and lower bounds to calculate it every time.

Sometimes which is better may be a toss-up. In those cases, you provide two functions, one that does the grunt work and another that’s just a wrapper that does the additional calculation:

count_iters(int start, int iterations) {
    // Do whatever this function does
}

count_range(int lower, int upper) {
    count_iters(lower, upper-lower+1);
}

Providing the wrapper centralizes the calculation of the number of iterations, which means that fixing a bug in it will correct the problem for everything at once and you won’t have to find and change every caller that’s doing it wrong.

Bottom line: If you pick one or the other arbitrarily or because someone says one style is better than the other, you haven’t examined the use cases and made a decision.

Which language? The answer to API design questions like this one is always language-specific. Many languages have built-in support for ranges. In those languages the answer is easy: use a single argument of whatever type is used to represent a range.

For Java, you might consider com.google.common.collect.Range from Google’s Guava library.

While exclusive upper bounds may seem unnatural, they are far more convenient than inclusive ranges because they eliminate a lot of fiddling around adding and subtracting one. Inclusive ranges over continuous types like time are very troublesome. How often have you seen things like { start: 00:00, end: 23:59 } ? What about 23:59:30 ? Using exclusive ranges eliminates those questions.