If you're going to talk about page boundaries-- which I think is a great idea-- then you should try to explain why programmers need to know about them and pay attention to them.
One importance is that when an indexed instruction or branch instruction crosses a page boundary, it adds 1 machine cycle to the instruction's execution time, which can interfere with the careful timing of a scan line display or other routine. Sometimes this could be used to advantage, such as if for some reason you need the instruction to take an extra cycle during a particular iteration of a loop. However, that is probably so rare and so difficult to manage (what with revising the program and so forth) that it's probably best to forget about entertaining such thoughts. ("This way lies madness!") More often you either try to position your data tables in memory such that they can be read via an indexed instruction without ever having to cross a page boundary, or-- if for some reason you can't or don't want to do that-- be very careful to compensate for the fact that the instruction will sometimes take an extra cycle. I seem to remember dealing with page-boundary crossings in my old "bitmap display" program for the 2600, although my memory is very hazy about that.
Another important fact related to page boundaries is that the 6502 processor and its kin (6507, etc.) had a famous bug in which an indirect JMP would end up jumping to the wrong address if the address in the instruction crossed a page boundary-- e.g., JMP ($10FF) is supposed to load the address that's stored at $10FF (lo byte) and $1100 (hi byte), but due to the bug it would actually read the hi byte of the JMP address from $1000 (i.e., in the same page as the lo byte of the address), with the result that the JMP jumps to the wrong place. To avoid this bug, 2-byte JMP addresses should always begin on even-numbered bytes so they don't cross a page boundary.
EDIT: I see RevEng already mentioned the extra instruction cycle; sorry for the repetition!
Edited by SeaGtGruff, Wed Mar 23, 2016 11:45 PM.