Is there any way to check which nodes are being rendered right now?

I am not sure if its a bug. Maybe I am just using it wrong. But I am 100% certain the BoundingVolume being wrong is at fault here.

By the way: The number of triangles are not the problem. I can render 100 million triangles at 50 FPS as long as the triangles are only about 1 pixel (or less) in size and all batched into a single draw call. Perhaps not with JMonkeyEngine, but when using raw OpenGL calls directly it works quite well.
However, for this particular application the numbers will not be that high. In these test images I am showing I am inflating the numbers on purposes to test the performance and to find the reason for the bugged BoundingVolume. After all, if I always got a nice frame rate I wouldnt have noticed the problem.

Could you please provide a test case to eliminate any outside interference. The person that fixes it will need it to repair it if it is indeed a bug.

A simple single class with the minimal set models to expose the bug.

Sure,

here is an example as simple as it gets:

import com.jme3.app.SimpleApplication;
import com.jme3.material.Material;
import com.jme3.math.ColorRGBA;
import com.jme3.scene.Geometry;
import com.jme3.scene.Mesh;
import com.jme3.scene.instancing.InstancedNode;
import com.jme3.scene.shape.Sphere;

public class Main extends SimpleApplication  {
    
    public static void main(String[] args){
        Main app = new Main();
        app.start();
    }
    
    @Override
    public void simpleInitApp() {
        Mesh mesh = new Sphere(13, 13, 0.4f, true, false);
        Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
        mat.setBoolean("UseInstancing", true);
        mat.setColor("Color", ColorRGBA.Red);
        
        InstancedNode instancedNode = new InstancedNode("Node");
        instancedNode.setLocalTranslation(128, 128, 0);
        
        Geometry geom = new Geometry("Geometry", mesh);
        geom.setMaterial(mat);
        geom.setLocalTranslation(0, 0, 0);
        
        System.out.println("Geometry.WorldBound="+geom.getWorldBound());
        System.out.println("@BEFORE_ATTACH Node:WorldBound="+instancedNode.getWorldBound());
        instancedNode.attachChild(geom);
        System.out.println("@AFTER_ATTACH Node:WorldBound="+instancedNode.getWorldBound());
        instancedNode.instance();
        System.out.println("@AFTER_INSTANCE Node:WorldBound="+instancedNode.getWorldBound());
        
        
        rootNode.attachChild(instancedNode);
    }
}

When I run the above code I get the following output:

Geometry.WorldBound=BoundingBox [Center: (0.005811617, 0.0, 0.0) xExtent: 0.3941884 yExtent: 0.39708355 zExtent: 0.4]
@BEFORE_ATTACH Node:WorldBound=null
@AFTER_ATTACH Node:WorldBound=BoundingBox [Center: (128.00581, 128.0, 0.0) xExtent: 0.3941884 yExtent: 0.39708355 zExtent: 0.4]
@AFTER_INSTANCE Node:WorldBound=BoundingBox [Center: (64.00581, 63.999996, 0.0) xExtent: 64.394196 yExtent: 64.39708 zExtent: 0.4]

The important part is the difference between @AFTER_ATTACH and @AFTER_INSTANCE. You can see the extent of the BoundingBox suddenly increase. The extent of the bounding box is dependent on the translation of the InstancedNode.

If I change the translation from (128.0, 128.0, 0.0) to (256.0, 256.0, 0.0) I get the following output:

Geometry.WorldBound=BoundingBox [Center: (0.005811617, 0.0, 0.0) xExtent: 0.3941884 yExtent: 0.39708355 zExtent: 0.4]
@BEFORE_ATTACH Node:WorldBound=null
@AFTER_ATTACH Node:WorldBound=BoundingBox [Center: (256.0058, 256.0, 0.0) xExtent: 0.3941884 yExtent: 0.39708355 zExtent: 0.4]
@AFTER_INSTANCE Node:WorldBound=BoundingBox [Center: (128.00581, 128.0, 0.0) xExtent: 128.39418 yExtent: 128.3971 zExtent: 0.4]

This seems obviously wrong to me.

there has been a recent commit to fix wrong bounds of InstanceGeometries

Are yo using master or 3.1?

The version is visible in the title bar of the screenshots above. It says v3.2-prealpha-sdk1-29.

v3.2-prealpha-sdk1 is 22.03.2017, so the patch is not in yet.

Well then it was most likely that bug.