But that second video. Bloody hell. It’s given me a much greater appreciation of the importance of how GM bakes in so much stuff. That you need a dozen lines of code for the GM equivalent of mouse_x, mouse_y kinda confirms that, yeah, GM is probably the place to start with making games…

ray start.z + distance * (ray end.z – ray start.z) = 0 so
distance = -ray start.z/(ray end.z-ray start.z

But that is just harder to read, not applicable to the general case and not actually faster in any measurable way. Mathematically speaking, it is exactly the same thing for the specific plane you’re using.

Now for a few tips, that problem you encountered with the camera requiring a rigidbody can be solved by script with a single line of code, you put this in your control script [RequireComponent (typeof (Rigidbody))] wherever you add said script will automatically add a rigidbody, obviously you can replace Rigidbody for other types of components, and it will automatically add those.
Also you can disable gravity on the rigidbody component, in fact you can make it kinematic which means it won’t respond to input from physics (which would make your script not work since it’s adding force to move the object).

Instead of adding several point lights to every scene you can instead go to edit -> render settings -> and change the color of the ambient light to something more white, ambient light, this will increase the ambient light of the scene making objects more visible (or less visible), alternative you can also use a directional light which acts kind of like the sun, and illuminates everything.

Also use ctrl+p to play and stop the game, and check vertex snapping, unit snapping, and surface snapping it will probably help you build levels faster.

Now for programming tips:

Don’t comment every single line of code, it’s not a good programming practice, comments should only be used as a last resort, when one cannot find any other way to make the code clear just by reading said code if you have this line of code:

Vector3 positionAfterTeleport = player.transform.position + teleportDistance;

there is no need to comment it out, since the name of the variables already says what the code is doing. One exception to this rule is XML method (basically what c# calls functions) commenting.

some of the reasons why you don’t want to comment every single line of code are:

If you change the code but you don’t change the comment (which happens more than one might think) which may lead to mistakes.
Reduces your ability to easily read the scope of the code, since effectively each line of code ends up taking two lines, halving the amount of visible code space.
In the end increases the amount of work, decreasing your ability to quickly change code, or test new things out in said code.

The out thing, in the raycast method is a way for a method to return additional variables, in the case of the raycast, all raycasts return a bool to indicate if they hit something or not, sometimes this information is enough and as such you do not require any more info from said raycast, however when you require the information about the hit (like where did it hit, at what distance did it hit, what collider did it hit and so on).
You can OFC create your own methods with your own outs, and you can use how many per method as you want, you can check msdn http://msdn.microsoft.com/en-us/library/ee332485.aspx in fact you should always check msdn for anything that is c# related.

In your ClickToCreate script you create a plane and raycast from said plane, an alternative to what you are doing could be to just simply put a plane in the scene background and raycast directly from the camera, you would get the raydistance from the difference between the camera and the plane z axis (you can also just give it a fixed distance, but less ideal in case you change stuff around), and you could spawn it using the returned x, y coordinates plus the z coordinate of the player (assuming you want to spawn stuff on the depth of the player).

Also a way to fix the all creating objects inside other obects is to see what the raycast hit, and then decide if it should create or not create said objects.
If for example you wanted to create objects in mid air (like those platforms) you would only create said objects if the raycast didn’t hit anything besides the plane/camera.
If you only wanted to create those objects when it hit other things, like say if you wanted a swing mechanic like on bionic commando, you would only create the object when it hit other objects.
This doesn’t fix things like creating an object that is half inside another object, but that can easily be fixed by just simply spawning a collider checking to see if there is any collision, and then proceed accordingly.

P.S. You wouldn’t need to implement your own physics system, nor should you, you can use box2d for 2d physics, and bullet for 3d physics, they are both free and open source, that being said I doubt you would need to do either of these things, since unity already has 3d physics, and the next update that should be around the corner brings 2d physics (although you can do 2d physics using 3d physics)

For the pointer position in world space you can use Camera.ScreenToWorldPoint with the pointer screen space position ( Input.mousePosition ) as a parameter. Note that the z position will be the z position of the camera so you will need to change it to the z position of the player ( or the z position you wants the cubes to spawn ).

http://docs.unity3d.com/Documentation/ScriptReference/Camera.ScreenToWorldPoint.html
http://docs.unity3d.com/Documentation/ScriptReference/Input-mousePosition.html

If you search the script reference you can find unity functions with examples.
Unity script reference : http://docs.unity3d.com/Documentation/ScriptReference/

If the game is only 2D you may change the camera projection to be orthographic.
Unity 4.3 ( currently in beta ) will bring a lot of 2D specific tools ( 2D physics engine, sprite support … ).

And this books covers the basic math involved in computer graphics and is quite simple. http://www.amazon.com/Math-Primer-Graphics-Development-Edition/dp/1568817231