XWiki 7.2 has introduced the concept of Nested Spaces. With this new concept it's legitimate to ask oneself what are the differences between using a (sub)wiki or using Nested Pages.

Summary

There are 2 main use cases when you'd use a Wiki instead of Nested Pages:

• You want to provide custom Applications/Extensions to a group of users of your wiki
• You want to implement an XWiki Farm where each wiki is seen as an island (own users, etc)

Features

Feature	Supported by Wiki?	Supported by Nested Pages?	Notes/Ideas
Set a custom Skin/Color Theme/Icon Theme
Set custom Panels
Delegate Administration/Right Management		*	An Admin can decide that such user or group has Admin rights on a Page and its children. [*] It's much harder to implement the rights for a Farm Mode when using Nested Pages than when using a Wiki, but it's possible.
Dedicated Users and Groups			Provides isolation, both in term of visibility and security.
Notion of Owner			The Owner has all permissions in a wiki
Ability to install JAR Extensions			Right now when installing with the EM UI, you cannot decide to install an Extension only for a Nested Page even though this is supported in the Core
Ability to install Applications/Flavors			Right now when Importing or using the EM UI to install an Application (XAR), it's not possible to root it under a certain Nested Page (i.e have it install itself relatively to a Nested Page). It's also not possible to install a Flavor in a Nested Page.
Ability to have a dedicated domain name/Clean URL scheme and Breadcrumb		*	[*] Possible but with some configuration: Apache-level config or URLRewriteFilter config
Ability to maintain the database easily			Subwiki use different schemas and this makes it very easy to maintain per wiki (for Farm use cases for ex). Database backups and restores can be done on a per-wiki basis. A wiki can be moved independently to another server (some links may be broken, depends on usage), providing solution to scalability issues. Extensions can create special tables in the schema of a given wiki (still needs some manual configuration). Schemas can also be optimized for specific purposes such as custom mapping.
Ability to easily query data across instances	*		[*] Because wikis are stored in independent schemas, you cannot perform a single DB query across multiple schema. However you can query content using the Solr syntax of the Query Manager which works across schemas. Nested Pages, on the other side, are within the same wiki, so within the same schema; it is possible to cover data stored in multiple Nested Pages with a single database query. For example displaying data coming different wikis inside a LiveTable is not easy and requires writing some custom JSON.
Ability to search in multiple instances			Solr indexes data independently from the database storage, so searching works across both wikis and Nested Pages.
Ability to create based on a Template with several Pages			Page Templates are currently only a single Page.
Creation/Deletion of Wiki or Nested Page	*		[*] Deleting a Nested Page will warn about broken links which is not the case when deleting a wiki. Also, you cannot rollback a deleted wiki, so unless you have a backup you've lost your data. You can't restore a deleted Page with a single click from the UI either, but at least you can restore each children Page under a Nested Page from the UI, or use a script. In other words, there's no Recycle bin for wikis.
Renaming of Wiki or Page			Page Rename updates backlinks automatically but it's not the case across wikis.
Invite Users			You cannot invite users only for a Page
Implement a "playground"			Nested Page share the XClasses. If you modify one XClass (e.g. XWiki.JavaScriptExtension) you affect all the Pages that use it. Wikis have to duplicate the XClasses, but this means the modifications are isolated. As a consequence, it's much harder (if not impossible) to implement a "playground" using a Nested Page than using a wiki.
Easiness of upgrades			Harder to upgrade XWiki: each wiki needs to be upgraded individually, even if it's only 1 click in the UI. Also it's slower to upgrade multiple wikis (e.g. when running database migrations since each wiki is a database).
Easiness of creation			While it's fast to create a space in XWiki, creating a wiki takes a lot more time. In addition, creating a wiki requires Create Wiki rights, while creating a page requires Edit rights.
Scalability			While the number of wikis is not limited, having an XWiki instace with thousands of wikis is not recommended (each "empty" wiki will contain thousands of internal pages) and thus doesn't scale in practice (long time to create, hard to upgrade). Also note the limitation that installing a XAR application on the farm means installing it on each subwiki which is resource consuming (time, memory).