With /interface pppoe-client, the situation is a bit simpler or a bit more complex depending on the goal. If you don’t need the checking of path transparency all the way to the internet, you can use the interface name as a gateway and you don’t need to care about the remote IP address of the tunnel. If you do need to check path transparency, you have to use the IP address of the remote end of the PPPoE tunnel, but the good news is that many ISPs never change it - there is no notion of a “subnet” on PPP interfaces, so the address they assign to you and the address at their end can be totally unrelated. So no need to adjust the address at their end when they give out another one for your end. But if you do need to track that address, make a copy of /ppp profile named default (or use directly that one, it depends on your general attitude to life) and configure the on-up script in a similar way like in the DHCP case, except that the variable names are different. Then tell the /interface pppoe-client to use that modified profile instead of default (or do nothing if you’ve modified the default). On the other hand, add-default-route is still a property of the /interface pppoe-client item itself, not of the profile.
The toughest time comes when you have two PPPoE connections, both give you the same remote-address (which can easily happen even if you have two distinct ISPs, as many use 10.64.64.64), and you still want to use path transparency check. In that case, there is no way to convince the recursive routing to distinguish between the two gateways (gateway=ip.add.re.ss%interface-name prevents recursive routing from working), and you have to use dedicated routing marks, netwatch, and scheduled evaluation scripts to track the path transparency. But be happy, that’s not your case.