A page is a region of virtual address space, and a page frame is a region of physical memory. A page which maps a region of physical memory must have the same size as that piece of physical memory, otherwise there's no point.
They also typically must be aligned correctly. If you try to map, say, a 2Mb page frame into virtual memory, both the virtual address and physical address must both be 2Mb aligned.
Many modern CPUs support more than one page size, and some can support different page sizes in the same address space. Current Intel x86-64, for example, supports 4kb, 2Mb and 1Gb page sizes. These numbers are not arbitrary; they represent the address space covered by different "levels" in the multilevel page table. Similarly, modern ARM supports 4kb, 64kb, and 1Mb pages, though ARM does not refer to the 1Mb pages as "pages" (they are "sections"). ARMv4 and ARMv5 supported splitting pages further into so-called "subpages"; these are no longer available in ARMv7.
Interestingly, there are a few other things that are often the same size as the page size. Obviously a TLB entry is the same size as a page or frame, since it's conceptually a cache for page table entries. However, L1 cache size is often determined by the page size, too.
Suppose the L1 cache is set-associative (a direct-mapped cache is really just a 1-way set associative cache, so you can think of this as a limiting case), then it's often convenient to make one "set" the size of a physical page. So suppose that the page size is 4kb, and the L1 cache is a 4-way set-associative cache, then the "best" size for the L1 cache is 16kb (which is four times 4kb). See if you can work out for yourself this might be the case.