Consider the extremes: if your team spends 4 weeks setting up for a 30 minute demo, something is clearly amiss. Similarly, if they spend 12 hours in that meeting, you're going to want to know what is going on.
These aren't reasonable numbers I've provided. More reasonable numbers are of course needed. This example merely exists to prove that a line exsists, so it can be meaningful to estimate at where it is.
However, the next question becomes what the consequences are of missing the deadline. In development, it can be a first indication of a problem codebase (hrd to maintain) or a problem developer (either not doing their work, or struggling with doing their work).
But the same metric doesn't apply to an overview/demo to new users (training) and potential customers (sales/marketing).
A training that takes longer might not be an indication of bad students (or a bad teacher). A sales pitch that takes longer isn't indicative of a problem if it actually increases the chances of selling the product.
Are estimates used as a way to justify what your developers spend their time on to non-technical management? Then you should put a reasonable limit on the estimate. Any deviation from the estimate can be justified by pointing out the unpredictable nature of the event.
This is no different from bughunting tasks. Some bugs are fixed in a matter of minutes. Others take days or weeks. You can't always know how long a problem is going to take to fix. The point of the estimate isn't to be correct, but to draw a line of reasonability, so you don't need to intervene with tasks unless someone raises a red flag or goes over the estimate and still hasn't delivered.
In my opinion, the bigger issue is that our team members are responsible for coordinating and in a way participating in these events.
If you mean that your developers should not be doing this job and someone else should do it, I don't quite agree.
If you mean that your developers' time spent on this should not count as development time, that is correct.
As a simplified example, let's say one of your developers is also a genius accountant, and the accounting department is in dire need of an extra pair of hands. The accounting department can't tell you how long they need him, all they say is "until the books are correct".
It makes no sense for you to put an estimate on the accounting tasks, since you're not an accountant. Secondly, an accountant's metric of success is not measured in the ability to predict outcomes but rather the precision of the actual outcome.
In these types of cases, you need to consider these demos/presentations are "development absences", i.e. the employee (not developer) is doing something for the company but is not performing development tasks.
But the logical consequence looms:
If I need to plan the next sprint, I need to know how long they'll be absent, and therefore I need to have an expectation of how long their absence will be.
You estimate their absence, but you don't raise a red flag if that estimate was bad. This is a matter of prioritization. If the company says that demo/presentations take precedence over development, then any justifiably absence due to demo/presentation is going to ruin sprint planning.
You can't avoid that. But the company also can't blame you for an inaccurate sprint since they themselves agreed that the demo/presentation took precedence.
This is effectively no different from a developer's absence due to sick leave, or your department not meeting the deadline because of an office fire. Reality took precedence over what you thought was going to happen. You can't avoid that. By semantical definition, you cannot expect the unexpected.