I've been trying hard to come up with a solution regarding this, but i haven't decided yet which one is the best.
From the perspective of an ISP, how do you characterize the p2p addresses given for a point-to-point connection to a)
customers with their own ASN b) customers without an ASN?
These are ip addresses configured on your router's border interface and on the customer's peer router interface (old
WAN-style), so they actually are both infrastructure and customer addresses.
So...
Do you consider them infrastructure addresses or customer addresses?
Do you put them in your IGP or in BGP?
Do you filter them on your border routers (via iACLs) and if yes, how?
Do you consider them infrastructure addresses or customer addresses?
They're infrastructure addresses.
Do you put them in your IGP or in BGP?
You should treat them as you do your other infrastructure addresses (i.e., if you're null-routing them at the peering edge, or what-have-you).
Do you filter them on your border routers (via iACLs)
Yes.
and if yes, how?
The same way you filter any other interface addresses in your iACLs.
Having an iACL format like below, that means that i would have to add at least one extra "permit" entry before the
spoofing entries.
deny MARTIANS/BOGONS
deny SPOOFING
deny PROTOCOLS/PORTS
permit BGP-PEERINGS
permit TUNNELS
deny INFRASTRUCTURE
permit ANY
If that's indeed the case, what non-routing protocols do you allow from/to these type of addresses?
Only specific types of icmp messages?
That, plus the routing session (if any) with your customer, plus anything else that's situationally-specific (GRE tunnel termination, etc.).
Roland, how do you handle customer requests regarding the remote management of their devices?
i.e. if the customer wants to do any kind of management (ssh, snmp) from outside his router, he must use our
infrastructure address (which is configured on his router) as a destination.
Generally, the customer might want to use this wan address for many other things which you shouldn't actually care,
since it's his router.
We generally perform all the management needed for our customer's circuits. If the customer is wanting to remotely manage their own router and etc then you should adjust your iACL to grant the customer access only on the IP on their router interface not the whole /30 or etc. Or if you've routed an IP range to that customer they can use that and pick an IP for mgmt stuff from that range and let your infrastructure be at peace. 
Also, if you are going to adjust your iACL for them you will want that customer to have a static IP address or range (not dynamic address) they are using to monitor/manage/access the infrastructure IP you've assigned on their router.
Otis
Well if you’re null routing the /30 then you or them should have a /32 or larger for NAT or no RFC space behind it.
Why would the customer not have a loopback interface configured on his router with an accessible IP address? Relying on the WAN address is arguably a poor choice for a number of reasons including renumbering events and circuit outages.
Yes, this is key. Management access to this router should not be possible from the public Internet at large.