Any block of physical memory can be "mapped" to appear at any position in the microprocessor's address space. As an example, take a small 1kB ROM/EPROM/EEPROM device, which has 10 address pins, allowing external circuitry to select any one of 1024 (0x0400) bytes inside the device, prior to reading data. This binary address will be anything between b0000000000 (=0x0000) and b1111111111 (=0x03FF).
Now we will connect those ten address pins directly to the lower ten address lines of a 6502's 16 bit address bus, A0 to A9, and (here's the important part) leave lines A10 to A15 unconnected.
Clearly, the microprocessor can place any value it likes on lines A10 to A15, and this will have absolutely no effect on which byte of memory is accessed. Only A0 to A9 have any influence. This has an interesting consequence, from the point of view of the microprocessor.
The effect is that the same block of 1kB of ROM appears at 64 different locations in the entire address space. The bottom 10 bits of the address bus repeatedly loop through 0x0, 0x1, 0x2 ... 0x3FF, 0x0, 0x1, 0x2 ... 0x3FF, again and again, 64 times, as the entire address bus counts from 0x0000 to 0xFFFF.
In other words, the first byte of the 1kB memory block can be accessed by the microprocessor at addresses 0x0000, 0x0400, 0x0800, 0x0C00, 0x1000, 0x1400 and so on, until 0xFC00. The second byte appears at 0x0001, 0x0401, 0x0801 etc.
Applying this same principle to your 32kB EEPROM, which has 15 address pins A0 to A14 connected to the corresponding pins of the microprocessor's address bus, with A15 being completely unconnected and ignored, you can see that the entire EEPROM contents will be duplicated (from the processor's perspective) twice, at 0x0000-0x7FFF, and again at 0x8000-0xFFFF.
The same program in that ROM will be present at 0x0000 and 0x8000, as far as the microprocessor can see.
The main takeaway here is that the address of the program in ROM memory, from the perspective of the EEPROM itself, and from the EEPROM programmer, is always 0x0000 to 0x7FFF, and yet from the point of view of the processor that program can be "mapped" to appear anywhere in the entire 64kB address space, depending on how it's wired to the address bus, and how the memory's "chip enable/select" pins respond to the upper address bus bits (called "address decoding").
The ".org" directive tells the assembler how to construct machines code to make it work at a specific location within the microprocessor's entire address space, but does not it any way determine or change the physical location in the device that stores it. So, when you write the assembly code, you are writing code to work at a specific place in the overall address space, but you can store that very code anywhere in the EEPROM, as long as you wire the EEPROM to appear at the appropriate place in that space.
So, in Ben's example, he's writing code to be assembled and run at position 0x8000, but that code is stored at position zero in the EEPROM, and the EEPROM is connected to "appear" (or be enabled) at position 0x8000 (and perhaps also 0x0000, if A15 is ignored as I explained above).
The EEPROM programmer has no idea of how the program works or was assembled, doesn't care if it's designed to run at 0x8000, or 0xABCD; all it cares about is that the file you are writing to the memory device begins at the device's own 0x0000 location. It's up to you to wire that EEPROM device up so that it appears at 0x8000 from the processor's perspective.
As for what's actually stored in the EEPROM, given the program you've shown us, if I recall correctly (30 year old memories being dragged up here), the first .org will not generate data. The following program segment appears at 0x0000 in the file. The second .org $FFFC will generate almost 32kBytes of zeros, then the last .equ will place 0x00 and 0x80 in locations 0x7FFC and 0x7FFD respectively. That's the end of the file.