Using RFC1918 addresses for router-to-router connections is frowned upon if it's on the public Internet, especially when used on an interface between the ISP and the customer (as opposed to between two routers inside the ISP network). This is because they reduce the usefulness of traceroute due to some sites blocking all packets to or from these addresses and because it is not possible to attach meaningful names to these addresses via DNS PTR records, because they cause routers to originate ICMP messages that cannot be traced back to their source, and possibly other reasons besides. However, it sounds like your ISP is set on using a RFC1918 /30 to number the interface between them and you. Despite the recommendation not to do it, it will actually work fine, and you can accommodate this situation with only one difficulty (see below).
The ISP's complaint about ARP trouble with a subnet larger than /30 sounds bogus. It is true that a router's performance can be affected by useless ARP requests for non-existent addresses on an interface with a large sparse subnet, but the subnet has to be both large and sparse (contain very many unused addresses) for this to happen. This is because only ARP requests for addresses that aren't used on the subnet must be endlessly timed out and repeated, which is how the router would get bogged down. If they upgraded your interface to a (public) /29, it would be neither large nor sparse (I am assuming that you would actually use all or almost all of the addresses on the /29). People are legitimately worried about ARP problems with /64 IPv6 subnets (which are obviously large and will always be sparse since the number of hosts on the subnet will never approach the maximum) but it sounds ridiculous to worry about it for a /29.
There is good news with this configuration: because the ISP isn't configuring your public /29 on any interface, there is no need to reserve the first and last IP address of the block as broadcast addresses, nor is there a need for the ISP to consume one of the addresses on their own router. So you get to use all 8 addresses for yourself instead of only 5.
Here's what you do:
Configure the interface facing the ISP with the 172.16.x.x/30 address provided by the ISP.
Add the /29 block to the lo interface:
iface lo inet loopback
up ip addr add a.b.c.d/29 dev lo
Set your default gateway to the ISP's side of that link 172.16.x.otherside.
Now comes the difficulty I mentioned earlier: by default, when your server initiates outbound connections (DNS requests, email going out, software update checks, outbound connections to databases, or whatever else your server does that is initiated by itself rather than by a client contacting the server), the server will use 172.16.x.x as the source address of the packets because that is the address attached to the interface through which the packets are going to egress. When the server attempts to contact destinations on the Internet at large using this source address, it will obviously not work. You need to give an option to the route command to install a default route with a customized source address.
Omit the normal
gateway 172.16.x.otherside entry and configure this instead in
iface ethSOMETHING inet static
[other configuration directives]
up ip route add default via 172.16.x.otherside src a.b.c.d
a.b.c.d, choose one of the addresses from your /29 which you consider to be your server's "main" address.