The key word in the standard is 'or'.

Two pointers compare equal if and only if both are null pointers, both are pointers to the same object (including a pointer to an object and a subobject at its beginning) or function, both are pointers to one past the last element of the same array object, or one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space.

If you have an array followed by a struct in the address space, compilers would layout the array and then align the start of the struct at a word boundary, not immediately following the array. In this case, the pointers are not guaranteed to be equal. In most architectures, they won't be equal.

The reason for mentioning array as a constraint is because the the arrays could contain anything: std::byte, char, int, long, double etc., Whether a pointer dereferencing operation will be successful or not depends on what is being pointed to and accessed. If you take a pointer to a specific byte in memory and dereference it as a long, if it is not aligned on a word boundary, you will get a segmentation fault. If you are dereferencing it as a char or std::byte, it will succeed. The pointer doesn't care about this, but the caller who dereferences it must. Keep in mind that pointers could be cast into different types before dereferencing.

This is the reason the standard specifically includes array.

As others have pointed out, the first part of the pointer equality condition in the standard helps with implementing iterators, array accesses, iterator::begin(), iterator::end() etc.,

Firstly, specifying array here does not exclude/forbid a single object. A single object in memory is indistinguishable from an array of size 1.

(Edit: Read this answer for a citation from the standard that explicitly states this when referring to pointers)

Secondly, the standard also tries to clarify the statement you have quoted, with the following footnote indicating scenarios where the rule applies:

Two objects can be adjacent in memory because they are adjacent elements of a larger array or adjacent members of a structure with no padding between them, or because the implementation chose to place them so, even though they are unrelated.

Putting it all together, what the standard tries to say here is that in general, two pointers to dissimilar objects should not compare equal. However, since it is legal to point one beyond an array object in memory, if there happens to be a different (array) object at that location, it is still legal for such a pointer to compare equal to a pointer to the adjacent object. Now, there may or may not be a valid object at this location, because of alignment choices and padding, but if there is one, it is acceptable for these pointers to compare equal.

In your example, if I changed the array to a char, the pointers would probably compare unequal because the compiler would choose to align the int to 4 bytes (on most 32 or 64-bit platforms), thereby introducing padding. This behaviour is still legal according to the standard.

#include <stdio.h>

struct test { char arr[10]; int i; };

int main() {
    struct test t;
    int *p, *q;
    p = (int*)(t.arr + 10);
    q = &t.i;
    if(p == q)
      printf("Equal pointers.");
    else
      printf("Unequal pointers.");
    return 0;
}

OP: Why the object following the array has to be necessarily another array?

It does not. "... start of a different array ..." is a simplification. The next spec is:

For the purposes of these operators, a pointer to an object that is not an element of an array behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type. C17dr § 6.5.9 7

OP: Couldn't simply be an object which type was the same as the array base type (like an int immediately following an int[])?

Yes.