While geo functions are interesting, I continue to feel they’re pretty niche as far as Fibery’s market is concerned. Which is a little ironic since I work in real estate so I’m one of the people that might benefit a little from it. 
But I think that may be also partly what informs my opinion that it should be low/no priority for the Fibery team. None of the use-cases you describe seem that compelling to me given the convenience of other options we already have. I’ll go case-by-case with your examples to explore a bit and then get to my proposed alternative(s) as far as Fibery functionality is concerned.
- Sales CRM: Does the map truly serve a functional purpose here that helps you “network a lot” with your clients? For seeing their (individual) locations on a map you can just right-click on a selected address and do a Google search and have a map extremely quickly. Of course if you really do want to see all their locations on a map together, it would help to have a map that could pull location info from Fibery. But for this specific situation it feels like there are probably workarounds via Integromat/Zapier or another integration that would do pretty well and not require a whole new type of data, new types of views (maps), etc. in Fibery.
- Event planning: I feel like this one is simple. Obviously you could do it outside Fibery, but I get that there may be value in having the Entity specifically associated with a position/location on a map of the event. However… I am a bit skeptical that actual geodata is at all necessary (or would even be useful) for this, depending on the size of the event. What I would do is just get a static image of a map of the area (could even be hand-drawn and scanned!), however large/small, and use that as a background of a Whiteboard and then you can easily add your Entity links, position them (or arrows to them) to show location, etc. What is much less obvious to me is any particular value from having the specific geocoordinates of these positions, and what you would do with that info in Fibery.
- Asset management: again, why is the map - the specific geo coords - useful in itself beyond just having an address or location name or whatever that tells you where the asset is? You could, for example, have 15 business locations, each one a Fibery Entity, and each Asset has a relationship with the Business Entity Type, so then you get a list of what Assets are at each Location. I don’t really see a major value in having a map associated with this, nor even specific geodata (e.g. lat/long, etc.), but I’m interested to hear if there are use-cases or situations I’m not thinking of.
The common theme in my above approach is to take the simplest route, to focus on the end result capabilities (finding something on a map of an event, knowing which assets are in which location, etc.), rather than to be looking at it as “all of these things have position information associated and therefore could be used in a geodata-aware system”. Perhaps there are other examples where a more clear and critical business case can be made to have it integrated in Fibery, or maybe I’ve missed or misunderstood some of the aspects in the examples, so feel free to clarify. 
That said, the one major piece of functionality that does suggest itself for most of these (and other) scenarios is the ability to embed arbitrary remote web pages into Fibery, like some other systems can do. This would solve at least some of the need here, I think, especially in combination with e.g. Integromat-driven integration to a mapping system from Fibery data. You could then have data in Fibery, push it out to a remote mapping service, and display the results within Fibery still. And the upcoming Block system would seem to be an ideal way to implement an iFrame, too, rather than having to paste arbitrary code into a page, or from the / menu, potentially making it difficult to edit, maintain, resize, etc. The Blocks seem to harmonize very well with the idea of an iFrame and the tools you’d want to manipulate it…
Bottom line, I’d like to see some of this discussion revolve around consideration of what kinds of more broadly useful/applicable functionality might help serve some of the core needs of this feature request (or at least an 80/20 view of what very few features would have the highest benefit/impact, like e.g. KML support as I mentioned above). It seems unlikely that dedicated geo fields will be added, or at least if they are, then unlikely that any full mapping functionality will be included (due to complexity, the “weight” of libraries to do it, API access and request limit complications, etc.). So if you take that assumption, then what creative workarounds can you imagine, that might suggest new features that the broader core use-cases of Fibery would also benefit from? (iFrame being my particular example)
Some related discussion is also in this thread: