Use a cube map and a geometry shader and you don't need to render the scene 6 times per light; it goes back down to once per light.

Also consider using smaller shadow textures for lower intensity lights.

Point lights are tricky, for the reasons you mentioned: using 6 depth maps per point light will consume a lot of memory and performance, so it doesn't scale up very well. For this reason most games don't support very many point light shadows simultaneously, or even at all. And if they do, they most likely stick to a resolution lower than 2K in order to save on memory and performance. The game that I work on uses a texture array of 16 shadow maps for point and spotlight shadows, so we would only support 2 point lights max (although in practice we avoid that case since we get a larger visual impact by reserving the shadow maps for additional spot light shadows). In light of all of this, it probably makes sense to give some deep thought as to whether the design of your game really needs multiple point light shadows. If it does, then here are some things you can consider:

1. Definitely "cheat" if you can with regards to carefully choosing which lights cast shadows. We do this all over the place. Artists choose which lights cast shadows, and also author distances at which shadows fade out. We also apply frustum culling (which you should of course do as well) to only render shadows that are within the camera's frustum, as well as apply pre-baked visibility culling. Our visibility system basically goes through our levels at certain points, and determines which meshes would be visibility to the camera and aren't blocked by other meshes. Then we also do the same for static lights, and also determine which meshes actually need to cast shadows for that light (skipping meshes that are completely occluded by the shadow of other meshes).
2. Depending on your game, you may be able to cache shadow maps so that you don't need to regenerate them every frame. The easy case would be a static light that's only casting shadows from static geo: you can generate that shadow map once, and keep using it until the light isn't visible or something dynamic moves through it.This doesn't help on memory, but definitely helps on performance. Even if there is a dynamic object moving through the light, you may be able to still only update that shadow map every N frames as long as the light is fairly far from the camera. You can also look into more complex variants of this basic idea, such as the one presented in this paper: http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=clustered_with_shadows
3. You can try looking into Dual Paraboloid Shadow Mapping as an alternative to cube maps for point light shadows. Dual paraboloid mapping lets you use only 2 maps instead of 6 since each map effectively covers a hemisphere. However the projection it uses is non-linear, so linear rasterization causes errors to occur. These errors may not be noticable if your geometry highly tessellated, so it depends on your game.
4. If you really want to get crazy, you can look into ray-tracing in the pixel shader or better yet cone-tracing through a voxel grid. These approaches remove the need for a shadow map entirely which can help for scaling up to arbitrary numbers of lights, but of course come with their own complications.

Use a cube map and a geometry shader and you don't need to render the scene 6 times per light; it goes back down to once per light.

This is true, but it comes with a significant GPU cost.

Use a cube map and a geometry shader and you don't need to render the scene 6 times per light; it goes back down to once per light.

That reduces the number of draw calls, but still requires rasterizing of the scene 6 times (once for each 2D surface) so the primary cost is still present.