Grouping utility methods for View classes
Refactoring and renaming isRightEdgeOfScrollViewHasBeenReached

How about like this:

public static boolean isAtRightEdge(ViewGroup viewGroup) {
    View childView = viewGroup.getChildAt(viewGroup.getChildCount() - 1);
    return childView.getRight() == viewGroup.getWidth() + viewGroup.getScrollX();
}


I haven't tested this, but it compiles.
As such, I don't really see a reason to limit the method to take a HorizontalScrollView as parameter.
Do let me know if you see some shortcomings in your tests.

Also, I removed the unnecessary parentheses from the return statement.

Organizing helper methods and utility classes

Here are some general tips:


Only move a method from your real class to a utility class if you will actually use it in at least two unrelated classes, right now. Don't add utility classes that "seem like a good idea", or if you're sure "you'll definitely use it sometime really soon". Don't speculate, wait until you have an actual use case.
Don't nest utility classes. Nested classes were not intended for this purpose, it would be misusing the language. This page in the docs explains when it is appropriate to use nested classes.
If you start to have too many methods in the utility class, or when it makes sense, split to multiple classes. (As you proposed in option 2.)
Avoid overloaded helper methods with the same number of parameters. (This is just a tip for the future, there was no such example in your post.)
Prevent instantiation of utility classes by adding a private parameterless constructor, for example:

private ViewUtils() {
    // utility class, should not instantiate
}