When obtaining IP resources from an RIR you're guaranteed that the block you're getting does not form part of a larger, advertised block. This is important for a few odd reasons that are not obvious.
The consideration below is that if you lease say a /22 block, that forms part of a larger /16 block, which can happen in a few cases, primarily when you procure a block from an upstream IPT provider (in which case most of the below is usually less of a problem) but in some cases also from alternative providers, that need not even reside in the same country as yourself.
The Root Cause
In order to avoid conflicts with existing public IP address space, let's assume for the moment that 192.168.0.0/16 is not RFC1918 covered IP and is owned by company called "Lessor". They have ASN 64512 (again pretending that private AS numbers are public) from which they originate this range. Let's assume they are based on the United Stated of America (USA). Now they lease 192.168.123.0/24 to a company we call "Lessee". Lessee originates this from AS 54513, based in South Africa (ZA).
As any good Internet Service Provider (ISP) would, the IP Transit (IPT) providers for both entities block the ranges they receive from their customers from other transit points. Specifically the IPT providers (recursively) for Lessor will not accept more specific ranges from other sources, and so, that IPT provider will not have the more specific 192.168.123.0/24 route available.
Problem 1: Non-reachability
As was already implied above, the IPT provider for Lessor will not have the more specific route if they're filtering their customer ranges from public exchanges, or private network interfaces. Thus any direct upstreams from the Lessor, and quite likely the lessor itself, is unlikely to have routes to the Lessee's leased range.
This can even happen in a case where the Lessor is leasing disjoint ranges from those it are using itself (meaning it's not advertising 192.168.0.0/16 and no less specific range compared to 192.168.123.0/24 if a route: object exists in the IRR system for the 192.168.0.0/16 range.
Depending on whether the upstream IPT providers from the Lessor is multi-national or not, this problem can be quite severe.
To solve this there has to be a direct inter-connect between Lessor and Lessee - which is not always practical, or Lessee also has to be a customer of all of Lessor's IPT providers. Even when this is solved it does not guarantee optimal routing paths, which leads us to problem 2.
Problem 2: Sub-optimal routing
Given the above, it should be plain that any ISP or IPT not accepting the more specific route will either be non-reachable, or at the very minimum have sub-optimal routing. There are a few trivial examples of this.
Using different IPT providers, these providers peer in-country, but Lessor's IPT blocks the more-specific advertisement from the Lessee's IPT, and routes the traffic to their default, which hits some other upstream IPT out of country that does have a route back to the more specific 192.168.123.0/24. In this case Lessee's path to Lessor will likely be fairly optimal, but the return path will not.
Variances of this scheme is also possible.
Problem 3: Updates to whois and RPKI
Depending on who you lease ranges from, since you're not in direct contact with the RIR, it has reportedly been difficult to get the Lessor to make appropriate updates to the whois database from the RIR, or even to get appropriate RPKI certificates published at same. This aggravates problem 1 above in that providers that should accept certain routes, even in other countries, simply don't.
Problem 4: Geo "Compliance"
Mostly we don't care exactly where IP addresses "reside". Nor should we (unless you're in law-enforcement, of course). But there exist a fair number of services (On-demand video Streaming providers being a very prominent example, but there are others) that's legally and/or contractually required to make content available only in specific "regions". Whatever the reason or motivation may be, there are arguably valid reasons for varying content based on location.
These services rely on databases that maps IP ranges to locations, in many cases the assumption is that ranges are used in a specific city, an assumption that can be disproven quite trivially. The auther himself works for an ISP that has two primary POPs where ranges are delegated to customers, usually in a dynamic manner for dial-in (FTTH and LTE) customers, such that the customer is not guaranteed to have the same IP consecutively. And it's been observed that often these ranges will in spite of geo feeds to the contrary be reported to the wrong city, and often not even in the right province.
It's been reported that these Geographic IP databases have in cases only looked at the outermost route in order to determine locality, and then when contacted would fix the problem, just to have it re-appear again in the future (as short as two weeks).
Conclusion
Unless you're leasing from a Lessor that knows what they're doing, and are responsive, you're going to run into an administrative and continuous trouble-shooting nightmare.
The only reliable fix is to ensure that unused space are returned to RIRs and control the delegations and assignments by way of policy.