What are the purposes of the ARM ABI and EABI?

ARM ABI should be referred when an OS kernel port on ARM is used.

EABI is when the processor boots to load an application with no intermediate kernel. (Something like there used to be ROM-BASIC when DOS came about), i. e. the firmware itself is the free-standing application, no board-specific monitor or anything.

The first link is to detailed sub-part related to procedure-calls of the ARM ABI. As the programmers' model advances with each version of ARM CPU, such topics are important and covered by ABI.

The second link is about binary format specification for object files generated by compiler called ELF that's specified by an OS vendor brand SCO. Perhaps SCO is Santa Cruz Organization that makes its own flavors of Unix as well as Linux, however that story deviates from the question. You should be interested in this if you intend to implement linker supporting ELF targeting ARM.

Unless you are directly concerned with implementation details of build tool-chain for ARM, EABI should be of little concern, and unless you are accounting for OS specific aspects of such tool-chain ARM ABI should also be of little concern.

ABI is basically how the function / procedures passes information to each other through registers (compiled form), where the return value stored (specify registers). In x86 or x86-x64 it is called ABI (Application binary interface).

In ARM architecture, it is knows as EABI (extended application binary interface). The ABI from before 2000 is known as OABI (old application binary interface), now this is obsolete. In EABI, the information / parameters passes in the forms of integers. the ARM processors who supports hardware floating point, passes parameters using floating point registers, called EABIHF (extended application binary interface hard float).

An ABI (Application Binary Interface) is a standard that defines a mapping between low-level concepts in high-level languages and the abilities of a specific hardware/OS platform's machine code. That includes things like:

• how C/C++/Fortran/... data types are laid out in memory (data sizes / alignments)
• how nested function calls work (where and how the information on how to return to a function's caller is stored, where in the CPU registers and/or in memory function arguments are passed)
• how program startup / initialization works (what data format an "executable" has, how the code / data is loaded from there, how DLLs work ...)

The answers to these are:

• language-specific (hence you've got a C ABI, C++ ABI, Fortran ABI, Pascal ABI, ... even the Java bytecode spec, although targeting a "virtual" processor instead of real hardware, is an ABI),
• operating-system specific (MS Windows and Linux on the same hardware use a different ABI),
• hardware/CPU-specific (the ARM and x86 ABIs are different).
• evolving over (long) time (existing ABIs have often been updated / rev'ed so that new CPU features could be made use of, like, say, specifying how the x86 SSE registers are to be used by apps was of course only possible once CPUs had these regs, therefore existing ABIs needed to be clarified).

Without some kind of this standardization, (machine) code created by different compilers couldn't use the same kind of libraries (how would you know in which way the library code expects function arguments or data structures to be passed ?).

Every platform (a combination of specific hardware, operating system software and code written in specific programming languages / compiled with specific compilers) defines a whole set of ABIs to make things interoperable. The terminology in this area isn't clear, sometimes people just talk about "the ABI", other times it's called the "platform supplement", or one mentions the programming language and says e.g. "the C++ ABI". Keep in mind, there is not one such thing.

The documents that you linked to in your question are all specific examples of this (language- / operating-system / hardware-specific ABIs).

Even on a specific platform, there's no necessity to have one and only one ABI (set) because different such conventions might have different advantages (and therefore provide better performance / smaller code / better memory usage / ... - depending on the program) and system designers usually try to be flexible / permissible.
On 32bit Microsoft Windows, for example, there's a multitude of ABIs (fastcall, stdcall, pascal, ...) for the function calling convention parts.

Anyway, a generic stackoverflow search for "ABI" (included the links under the "Related" sidebar) gives so many leads to researching this question that I close my answer at this point.