I've done a few tests with GDScript.

There isn't the same depth of library support as Python for obvious reasons, which makes the experience different even though the syntax is pretty close, but it's not worse at the task of doing things with the engine, in fact it's better at that because it's more deeply integrated(which is the point of having a custom language). It's aware of engine core stuff like e.g. geometry vectors and the scenegraph, and the built-in IDE supports working with GDScript directly with no configuration step needed - edit/test/debug all done exactly like it should be.

Performance-wise, it's fine for what it's intended for - running gameplay logic for a game of small-to-midsize scope(think ~$5mm budget) that isn't trying to drive tens of thousands of entities or run parts of the rendering from script. Smaller games can get away with optimizing hotspots, and a bigger game can start to justify having someone forking the engine and poking around in the internals to optimize whatever part of the architecture starts falling over.

For the use-cases of running a specific task that's more intensive or bolting on some additional dependencies, the new GDNative support is compelling. Godot's stated aim is for convenience over optimization but the optimization is definitely present in critical elements.

I worked on a small project in Godot and I found the transition from Python to be pretty natural. Here's the GDscript primer if you want to take a glance:

http://docs.godotengine.org/en/3.0/getting_started/scripting...

If you want to use pure Python for your project, a binding using GDNative exists, although it seems quite new at the moment... https://github.com/touilleMan/godot-python

To see a glimpse about performance with GDScript: https://github.com/cart/godot3-bunnymark