Short explanation:
This is indeed how NES palette attributes work.  Working around it is part of the NES charm.
The 2x and 4x grids help a lot with planning it out.

Long story:
Inside the NES, there's 2 kilobytes for background placement data, which covers two screens at a single point in time. 
So, 1 kilobyte per screen. A screen table is then comprised of two separate tables: the nametable, which says which tile index (name in official nintendo jargon) is used where. This covers 32x30 tileplaces, and takes 1 byte per cell, so 960 bytes. You then have a meagre 64 bytes left to cover the whole screen with palette attributes. That's one byte per 16 (or 4x4) tiles! The NES's solution to this is let 2 bits out of the byte (representing subpalette 0,1,2, or 3) cover 2x2 tiles (a quarter of the bits in a byte for a quarter of the area the byte must cover), so the highest possible palette resolution is still 2x2 tiles (16x16 pixels) large. 

Now, there are some cases where the NES's internal background memory can be circumvented to provide for more detail directly from dedicated extra hardware on cartridge - the MMC5 mapper is famous being able to provide a single screen of per-tile attribute data) - but in practice, 99.95% or something like that games never do that due to a number of intricate concerns. Even the ones equipped with MMC5, it's surprisingly rare. 

Per-tile attribute support is planned for in version 4.x if i ever get there, but it won't be default behaviour as that's not what the NES is typically known for or able to produce, and the only physically available mapper right now that can produce those results (the Rainbow mapper by Broke Studio) only has partial emulator support so far. MMC5 is out of the picture since there are no available sources for new mmc5 chips.