> I'm fairly certain that changing the MTU should be the LAST thing that a helpdesk or general support staff should be doing, and instead additional tests on configurations, etc. on the system itself should come first.

Most definitely. Changing an end system's MTU should definitively be only the last straw. 

If there is a reduced MTU link somewhere in the path (and if PPPoE is in the game chances are high that there is), then make sure...

... on the network, from end system to router/gateway
 - full support for Packets/Frames with a L3 payload size of 1500 on all links.

... on the router/gateway which has the reduced MTU link attached:
 - respects the *don't fragment* bit set in packets travelling through (in extenso: does not do "df-bit ignore")
 - sends *ICMP unreachable,  Fragmentation Needed* messages (Type 3, Code 4) for packets too large to fit into the reduced MTU link.
 - performs TCP MSS clamping (Cisco speak: "ip tcp adjust-mss") to an appropriate value (e.g. 1452 for an 1492 MTU link), if possible in both directions. 

... on the end systems (although this is bordering to be off-topic to this board)  
 - Investigate if the given IP stack supports PathMTUDiscovery and if it is enabled (i.e. if the IP stack actually ingests and processes the fragmentation needed messages), 
 - If the devices 'security features' (as in "host based firewall") don't prevent ingestion of fragmentation needed messages because some 'security admin' ruled that "ICMP unreachables are bad, m'kay?"