Service vs Location as Second Octet

I'm sure this has been posted before, but my google-fu is failing me.

I'm working on our IPv4 addressing scheme at the small startup where I work. We had a contractor do most of the network work, but they are not being super responsive and didn't know how to do a couple of things.

I'm an SRE so this is totally within my domain and I have some experience running more complicated (but small!) Networks. I'm also trying to improve my network chops, and I'm not totally out of my depth, so I jumped in. That being said, my experience is with very small nets, and designing for orders of magnitude growth & w/ multiple sites is new territory for me.

We currently have only one location, but a number of remote workers.

Are there any significant advantages or disadvantages to associating service as the second octet of a class A network, and location as 3rd octet or breaking it down into smaller blocks from there?

The main advantage I can think of is remote workers... Break off a /16 for BYOD and dole out small blocks for each remote person. That would appear to allow you to set up routing and monitoring rules per-employee more easily. Though I suppose you could just as easily allocate a /16 for remote workers and do something similar.

The main disadvantage I can think of are larger routing tables... But how much larger would they be, really? I don't really know how to set up the equation for this. Shot in the dark is servicesxlocations where first octet is just locations so worst case is 254 vs 254^2? If your router is using a balanced-btree internally, that should be 2x lookup time, right?

By the time we've got more than 254 services or sites we'll have full time network engineers to refactor this so I'm not super concerned about scalability above that point.

Things like "this requires a manual change for every new hire or fire" don't phase me--I'll just add it to our onboarding / offboarding automation, etc.